Discovering possible federation approaches: XMPP (original plan) Etherpad approa
Discovering possible federation approaches:
- XMPP (original plan)
- Etherpad approach (maybe spiced up with Matrix)
- Deltachat approach (federate over email)
- New custom protocol
- Sync over Git
- Sync over Dolt
- IPFS-based approach (P2P)
- Custom P2P approach
Curious how much of these you understand and what seems best to you. We could even combine several.
Thanks, yeah will review with ChatGPT
I have a possible approach. It looks like we can almost fully reuse the XMPP stuff in there, but simplify the server setup parts using the Matrix approaches, which are much simpler to configure. Spec here: https://github.com/LaPingvino/incubator-wave/blob/federation-spec-draft/docs/wave-federation-spec-draft.md
cool, i will read it
Thanks Joop — I like the direction, especially the push toward HTTPS, /.well-known, and a simpler operator story. I also agree that the existing federation interfaces are the right seam.
My concern is that the draft currently reads as a transport swap, while the codebase is still much more coupled to the existing signer-info / X.509 trust model than that implies. So Ed25519 + HTTP key fetch is not just a transport change; it needs a much tighter trust, rotation, and historical-verification story first.
I also think snapshots, alternate encodings, and the WebSocket delivery model are all too underspecified for v1. For me, the right next step would be a much smaller compatibility-first draft: protobuf only, HTTP submit/history first, no snapshot in v1, and trust/tooling split into separate documents.
The shareable-links / guest-access track looks like the strongest near-term product direction. For federation, I’d keep the goal but narrow the scope before treating this as an implementation plan.
Here's complete CHatGPT review
let me know what you think
The issue here is that protobuf itself can make implementation harder to get right... Also the snapshot approach can help to compensate for issues in earlier implementations for example. I think the shareable links approach is a nobrainer for sure. I already asked Claude to try implementing a version of the document on my fork, you could play with that stuff, I haven't tested any of that yet because I don't run a test server yet...
Agree, protobuf makes is harder for humans, but for protocol it is generally good choice.
For stability yes, and I guess we'll need that for wave... But it's not as easy to flexibly upgrade as JSON etc...
Can you create PR with the feature?
Can you try to figure out how much of this is true/relevant? I think it's extremely revelant to document how much/in which way this is the case.
hm, interesting. this one was written in-line but isn't rendered there...
I think you need to select text before clickign on reply to be rendered inline
I did that, and it worked inline correctly, but appeared at the bottom after the refresh. Also, I had this message written out longer before, but I just had to edit it again because only the "I did that" was registered...
This blib came from a misclick... probably good to fix that too...
Can you describe exactly what happened?
So, many places, like the bar below another message, create a new blib. This is correct and desired, but it's probably good to auto-remove it if no typing starts or e.g. via esc on an empty blip. Not super important though...
BTW, you can turn URLs into links using the link button on wave editor panel :)
Join the conversation on SupaWave
Open in SupaWave