Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message Rewrite Facility-like system #160

Closed
aumetra opened this issue Apr 4, 2023 · 8 comments · Fixed by #490
Closed

Message Rewrite Facility-like system #160

aumetra opened this issue Apr 4, 2023 · 8 comments · Fixed by #490
Labels
enhancement New feature or request exploration Exploration of new ideas

Comments

@aumetra
Copy link
Member

aumetra commented Apr 4, 2023

Somewhat of a followup to #140/#159 (since this system could potentially deprecate them)

I would really like to have a system similar to Akkoma's "Message Rewrite Facility" system (https://docs.akkoma.dev/stable/configuration/mrf/).

Somewhat related to #132 since we have to figure out what "scripting" system we want for these facilities.
The current main candidates are:

@aumetra aumetra added enhancement New feature or request exploration Exploration of new ideas labels Apr 4, 2023
@aumetra aumetra changed the title Messare Rewrite Facility-like system Message Rewrite Facility-like system Apr 5, 2023
@erlend-sh
Copy link

erlend-sh commented Apr 7, 2023

WASM would be great (multi-lang support!), but the ecosystem is still in flux. Many different approaches to consider.

Another good candidate is Rhai:

On that note, here’s an interesting discussion considering the trade offs between Rhai and Deno, albeit for a different use case: aurae-runtime/aurae#35

I think one interesting point in Rhai’s favor not mentioned there is that it supports WASM. Meaning, for a scripting system with a long term plan to use WASM, Rhai can serve as an intermediary step, starting as the singular scripting language until it’s eventually delegated to one of many options when WASM is introduced as the primary scripting platform.

@silverpill
Copy link

+1 for WASM. I'm considering it as well, because WASM MRF modules can be reused by other implementations.

@aumetra
Copy link
Member Author

aumetra commented Jul 10, 2023

@silverpill Interoperability would be really nice. I think an API such as

$$ (retCode, newActivityOption) = f(activity) $$

should be sufficient for a start? That should be possible since WASM does have the possibility to return multiple values now.

Or the newActivityOption could be an externally tagged union, where retCode implies the type of the union. Enough options to think about, I guess

@silverpill
Copy link

Yes, that should be enough. In the future it would be nice to also expose some kind of API to MRF module (to let it read some data from database, for example).

@aumetra
Copy link
Member Author

aumetra commented Jul 10, 2023

Definitely. Maybe we should define some kind of API together and specify it somewhere so at least Mitra and Kitsune stay in sync.
Versioning could potentially be done via an global export of an i32 or something as a version discriminant

@silverpill
Copy link

That would make a good Fediverse Enhancement Proposal :)
I can't start working on it right away though, need to finish a bunch of other tasks first, and I haven't worked with WebAssembly before... So I will probably follow your lead.

@aumetra
Copy link
Member Author

aumetra commented Jul 11, 2023

I guess that would also be a nice preparation for me to write an FEP before I attempt to write the "identity proof login" FEP, heh

@erlend-sh
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request exploration Exploration of new ideas
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants