spark 1731620099981

Allowing Rainbeam instances to communicate with each other

Hey!

Over the past few days, I've been working primarily on federating/decentralizing Rainbeam servers. To do this, I've drafted the Citrus Protocol.

This protocol allows Rainbeam servers to communicate with each other through sharing schemas which document return objects and API endpoints. Rainbeam servers will now publish their citrus.toml file at /.well-known/citrus/citrus.toml, as well as all of their schemas at /.well-known/citrus/schemas/structs/**/*.

This is all still very much a work in progress, so expect many things to change. Currently, GET requests sent to the responses API will now return the response ID in the CitrusID format. This means that response IDs are now shown as neospring.org:RESPONSE-ID.

In the coming days, I hope to finalize this protocol draft and start actually forwarding requests to remote responses.

Currently, response IDs given to methods in the rainbeam-core Database are converted into a CitrusID (using the WIP client available here), but then just have their server_id field discarded. Soon, I hope to begin actually paying attention to this field and forwarding requests using the client to remote servers.

Thanks!


Posts from blocked users should now no longer be shown in the posts timelines. I hope to expand this to global question timelines in the near future!


*It's not based on Activitypub because the Actvitypub protocol is too complicated and would require rewriting a large part of Rainbeam's core.


Reactions

Comments
Leave a comment

hell yeag

EDIT: But how will users from other servers look like? Like "@user@server" or something else?

system32 1731679466125 *

Pressing continue will bring you to the following URL:

Are sure you want to go there?


Continue