2023-11-20 16:15:57
- reply
Following up with this talk, since an event is immutable. It makes no sense to have a stream of immutable data of 1 item.
put in programming term:
get(event_id) -> stream<event> makes no sense
get(event_id) -> event | nothing makes sense
Then, we should just have
http get/post for read/write a single event.
Web Socket everything is overrated.
The only use case that might justify stream of 1 event is that at the moment of querying, the event is not in the relay, but in the future the event might be published to this relay by other clients or relays.
But, in order for a user to even know the ID of an event, the event has to exist in some relay before the time of sharing.
http get(nevent) always makes more sense.
2023-11-18 05:57:12
- reply
A problem has been bugging my mind since the ever beginning.
What should be the role of relays?
If we treat it as a node of a distributed system, such as a Cassandra node, then it should not differentiate and clients just treat it as an opaque network & storage layer. All the replaceable events & consistency discussions come from this angle.
If we treat it as a discord server or a Slack workspace, then each relay differentiates in content and possibly in functionality.
Right now, most developers seem to want relays to be both. But these 2 have very different design trade offs . Wanting to be both might just end up being good at none.
Or, maybe some developers haven’t thought of it consciously.
Fruit for thought: should relays be aware of each other? Should the awareness be mandatory like a distributed system or just a nice to have?
For example, a DM client has very different needs for relays from a social client.