undefined | Better HN

0 pointsthomastay1y ago0 comments

yeah, having eventual consistency for messages across homeservers makes the work on the client harder. I guess they just have to accept that messages will "appear in the past" as you said.

But at least for messages sent within the same homeserver, I would think that those two apis should return the same data

0 comments

fiddlerwoaroof1y ago

I think you basically want a partial order for federated chat: messages should arrive after the messages that cause them but not necessarily after messages that didn’t cause them. In the case of a network partition, this allows people on either side of the partition to continue communicating at the cost of non-determinism when the partition is resolved.

duskwuff1y ago

I'd maintain that an important property is for the system to be eventually consistent with regards to history. You don't want a transient network event to potentially result in two users permanently seeing messages in a different order.

fiddlerwoaroof1y ago

I don’t think you can prevent that without centralizing on a single server

1 more reply

j / k navigate · click thread line to collapse

0 pointsthomastay1y ago0 comments

yeah, having eventual consistency for messages across homeservers makes the work on the client harder. I guess they just have to accept that messages will "appear in the past" as you said.

But at least for messages sent within the same homeserver, I would think that those two apis should return the same data

0 comments

fiddlerwoaroof1y ago

duskwuff1y ago

fiddlerwoaroof1y ago

I don’t think you can prevent that without centralizing on a single server

1 more reply

j / k navigate · click thread line to collapse