anytime a gate prints with a complicated sample or product type it is
frequently extremely long. 3 is probably too low of a cutoff number, but
ideally a future version will have verbosity settings that will help
control this.
Adds .snub to ames-state, a global blocklist for ships. If a packet is
received from a ship that is in the .snub set, it is immediately
dropped. Adds %snub to ames' $task, to allow manipulating this list
all this did was set .nut. while it could be used with doccords, it is
currently unused, and none of the other values in the sample of _ax are
set this way (bug, def, cox, hay, dom). i experimented a little bit with
trying to make use of this but it made things overall more unreadable,
and it wouldn't make sense to do it without doing the same for other
values of the sample. im guessing this is just an old style.
Previously, fake breaches triggered by a %ruin task would only get sent to
subscribers watching for the affected ship specifically. Now, we send them to
both those subscribers, and the ones watching for pubkey changes on all ships.
%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.
Fixestloncorp/landscape-issues#1442
