urbit/bin/multi-brass.pill

version https://git-lfs.github.com/spec/v1
oid sha256:ea8626444e4f0213e39c21ded20607145ee85a947afc592f182f46e7f598ef30
size 7748671
pill: generate brass multi-desk pill 2021-09-29 16:19:24 +03:00			`version https://git-lfs.github.com/spec/v1`
contact-store: no-op if adding old contact %contact-store is responsible for sending updates about contacts, eg profile color. When it hears an update, it fans that out to its subsribers, unless that update is stale. If you reguarly fan out stale updates, then they reverberate across the network indefinitely -- we call this "echoing". To cut off this echoing, all edits have a timestamp, and we consider any updates from before this timestamp to be stale. Additions are separate from edits, and for them we instead do a value comparison on the contact -- if it didn't change, we consider the update stale. The problem with this scheme is that if an addition and edit happen one after the other in quick succession, you might have the following sequence: - add comes in with timestamp T1 - edit comes in with timestamp T2 after T1 - we hear an echo of the add, and that errantly applies because it passes our "did the contact actually change" check - we hear an echo of the edit, which applies because T2 is after T1 - GOTO 3 Each time we apply the stale update, we fan that out to our subscribers, and if any two hosts subscribe to each other, this will loop. This may even loop unconditionally because the ship that made the profile changes seems like it might not recognize that those changes didn't come from itself, so it sends them to all the groups it's in. If so, that's an important issue to fix. Fixes tloncorp/landscape-issues#1442 2022-12-12 23:03:41 +03:00			`oid sha256:ea8626444e4f0213e39c21ded20607145ee85a947afc592f182f46e7f598ef30`
			`size 7748671`