Cool! We have been building feeds on braid, too! It would be very interesting to support FeedAPI with Braid -- you would get much faster pushed updates than y

Cool! We have been building feeds on braid, too! It would be very interesting to support FeedAPI with Braid -- you would get much faster pushed updates than you currently do with client-pulled updates! See our current work on the "feed" spec in Braidmail: https://braid.org/apps/braidmail/spec2 https://braid.org/apps/braidmail/spec2. To support event-sourcing, you could replace those {link: ...} objects with event objects, and just treat each event as data. Then you'd have a url like /event-stream that peers would subscribe to. Or, you could go deeper, and come up with a custom `Patch-Type:` for your events, which could make your events first-class HTTP citizens that could also be applied to a server using the PATCH method. Then your url might be /system-state, and represent the state for the whole system. Braid supports such custom events, but be aware that this model is limited in a few ways: - It's less interoperable, because all peers must know and implement the custom event types (aka patch-type) in order to read or write state. - You don't get to re-use the beautiful and complicated merge algorithms that support eventual consistency with multiple writers (the OT/CRDT algorithms). - It doesn't allow summarization of history. It's hard to prune history when each peer needs to know all events in order to do anything. You might also be interested in PREP, which is a pure event-update protocol being worked on by my colleague Rahul Gupta: https://github.com/CxRes/prep https://github.com/CxRes/prep We're trying to merge our work together, if we can. You might also be interested in our deliberation on the pros/cons of "events" vs. "state updates" here: https://github.com/braid-org/braid-spec/issues/102#issuecomment-1770468174 https://github.com/braid-org/braid-spec/issues/102#issuecomm...