Ie is it a series of messages? Or is it something more advanced; with built in conflict resolution or other P2P-y features?
Regular Matrix is pretty straight-forward - you join rooms and send events. Events get propagated to all participating/federated servers that are in the room. You watch for incoming events.
The Matrix devs should be able to say more about their P2P implementation. :)
I can't tell what language Hummingbard is coded in. Hint?
GPL with targeted relaxations is usually a good way to start. You can always relax the license more later if you exercise the foresight to get contributors to allow relaxations per your judgment; and, don't rely on any strict GPL dependencies. Being GPL but not able to use GPL libraries is a funny position to get into, but that's our world.
If you want forks accessed via the network to publish source code, use the AGPL, otherwise you may as well just use the MIT licence.
From the client's perspective, matrix is just a basic stream of events (like XMPP). The magic happens on the server side where a room is replicated across servers and conflict-resolution voodoo is applied. That's also why synapse server is really really resource-intensive (gigabytes of RAM) compared to equivalent-in-features (apart from decentralized rooms) XMPP/ActivityPub servers ; dendrite is fairing better but i haven't benchmarked it yet.
Synapse’s RAM usage is a) way better these days, b) not due primarily to the merge resolution algorithm (state res), but due to slapping in-memory caches everywhere rather than being smarter on the db schema. Dendrite does 5x better by being smarter in the schema, and Conduit looks to be even better via cunning use of using key/value dbs for persistence (sled).
Eg, for sake of simplicity, imagine you're storing Git in Matrix (similar to what i'm doing, if i use Matrix). I've got two primary concepts:
1. A mutable set of pointers.
2. A series of key values, where the keys are content addresses, and the values are a byte array.
My initial assumption would be to use the messages to post all newly created blocks and changes of pointers. Eg, Send a message with a new content address and the bytes. Send a message with a new address for a pointer.
For a Git-like to work in that model, it just needs to slurp up any messages in the datastream. Making sure to also slurp in old messages properly that maybe are out of order (ie, reconnecting after being offline for a while). But being a Git-like, it's a fairly simple model.
With that said, perhaps the metadata storage in Matrix would better suite some of this? I just imagine Matrix isn't intended to host TiBs of `/state` metadata.
Thoughts?
In the longer term we'd (well, I'd) love to make it work well with freeform KV data (or object graphs! you gotta store your VR scene graphs in Matrix, after all) and act like some kind of crazy global zero-trust CouchDB or Cassandra. But right now the KV state is meant to be for relatively simple freeform metadata about a room.
That would be great for a decentralized forge based on matrix. This is an area where i think matrix decentralized rooms would shine, as they would effectively prevent DMCA takedowns for software projects.
Thanks for the clarification. My point was that building something client-side for matrix is pretty straightforward, in case that was not clear.
> not due primarily to the merge resolution algorithm (state res), but due to slapping in-memory caches
Good to know. conduit doesn't quite look to be ready, but would you recommend using dendrite in production to serve a few users? i guess i'll give it a go