I do think the other home server implementations gaining parity (production-ready) with the reference home server would go a long way. I haven’t run a home server but I’ve heard from those that have that it really has a hard time scaling. (Though this serves as impetus to give it a try over spring break)
Which brings me to the caveats of the protocol, I personally don’t think the design is ideal, it’s more described as a distributed message bus, what I’ve read of the spec it’s over engineered, it made good decisions wrt using modern web technologies (JSON, WebRTC), but it didn’t scope itself to the particular task.
That said, I haven’t written a federated protocol, and they have.
But if I was going to, I’d really want to look at Discord and see how to copy a lot of that model, but break parts of it out to facilitate federation:
I originally wrote a huge hypothetical design here that I speculated would fare better, but honestly the specifics become less relevant, point is that the shared state of rooms is a real challenge, and one out of scope for just a federated instant messaging system, and I’m no longer certain it’s viable.
I’m personally more interested in P2P protocols than federated, so that’s the stuff I build in my spare time.
So instead of something like Lemmy or Matrix, I’d have something like BitTorrent or Tor, so nodes just add capacity instead of hosting specific content. You could configure your node(s) to pin specific content (e.g. for backups or latency), but your data would also be distributed to other peoples’ computers.
This provides data redundancy, permanency of the service (no centralization whatsoever), and ease of scaling (every client could store and seed data), but comes with complexity. I think it’s workable though.
I do think the other home server implementations gaining parity (production-ready) with the reference home server would go a long way. I haven’t run a home server but I’ve heard from those that have that it really has a hard time scaling. (Though this serves as impetus to give it a try over spring break)
Which brings me to the caveats of the protocol, I personally don’t think the design is ideal, it’s more described as a distributed message bus, what I’ve read of the spec it’s over engineered, it made good decisions wrt using modern web technologies (JSON, WebRTC), but it didn’t scope itself to the particular task.
That said, I haven’t written a federated protocol, and they have. But if I was going to, I’d really want to look at Discord and see how to copy a lot of that model, but break parts of it out to facilitate federation:
I originally wrote a huge hypothetical design here that I speculated would fare better, but honestly the specifics become less relevant, point is that the shared state of rooms is a real challenge, and one out of scope for just a federated instant messaging system, and I’m no longer certain it’s viable.
I’m personally more interested in P2P protocols than federated, so that’s the stuff I build in my spare time.
So instead of something like Lemmy or Matrix, I’d have something like BitTorrent or Tor, so nodes just add capacity instead of hosting specific content. You could configure your node(s) to pin specific content (e.g. for backups or latency), but your data would also be distributed to other peoples’ computers.
This provides data redundancy, permanency of the service (no centralization whatsoever), and ease of scaling (every client could store and seed data), but comes with complexity. I think it’s workable though.