[ANNOUNCE] 410k-1
25 views
Skip to first unread message
Pyry Kovanen
May 28, 2025, 9:27:10 AMMay 28
to urbit-dev
%base hash: (check with +vats %base, =verb %.y): 0v1f.9teg3.e6538.1r1ha.g3d06.am3ht.1rj7i.4doco.saini.3rag8.dm94r
410k-1 is a minor bugfix release addressing the following issues:
* Directed messaging was unable to handle a very old wire format existing on some old ships.
* Ships that were converted to directed messaging were not properly being reset back to old ames when they breached.
* The interface for for %keen was extremely confusing in 410. The gift that was received was a %tune from peers using old ames and a %sage for peers converted to directed messaging. In this 410 release we change these to always return a %tune. In the next 409 release we will consolidate everything to a %sage which is the new directed messaging gift.
* When communicating with a moon a ship always asks its parents for the keys of the moon. If by some unfortunate circumstance the parent crashed just as it received the request for the moon keys they would never get delivered, and communication between the client and the moon would never happen.
This release also adds support for using Authorization headers instead of cookies for Eyre authentication, double boot protection fixes and many directed messaging bugfixes.
The most important change of this release is the following:
Urbit provides extremely unusual guarantees for userspace Gall agents. Namely, when you poke or subscribe to a ship it is guaranteed that these actions will eventually be delivered to the ship without a need for the userspace application to have any retry logic. This guarantee is implemented through Ames retrying these pokes or subscriptions every 2 minutes until the ship in question responds. In normal operation all is at it should be, however...
If a ship receives a poke or a subscription for a Gall agent that is not active it will ignore the packet. This design decision enables a kind of reactivity later if the ship does install the agent. But if this ship never installs the agent then the sender is on the hook to send this packet every 2 minutes forever! And even though the receiver ignores the packet it still gets written to disk through the event log. We have seen ships in the wild with a hundred thousand of these "dead flows" firing every two minutes. Most older ships suffer from this issue, and notably there is currently no way to recover from the dead flows other than breaching.
If your ship feels slow the root cause is almost always these dead flows.
410k-1 provides the first layer of mitigation for these dead flows. Every message that has been tried 100 000 times or more will now back off to a day instead of two minutes. We have other mitigations in the pipeline.
410k-1 is a minor bugfix release addressing the following issues:
* Directed messaging was unable to handle a very old wire format existing on some old ships.
* Ships that were converted to directed messaging were not properly being reset back to old ames when they breached.
* The interface for for %keen was extremely confusing in 410. The gift that was received was a %tune from peers using old ames and a %sage for peers converted to directed messaging. In this 410 release we change these to always return a %tune. In the next 409 release we will consolidate everything to a %sage which is the new directed messaging gift.
* When communicating with a moon a ship always asks its parents for the keys of the moon. If by some unfortunate circumstance the parent crashed just as it received the request for the moon keys they would never get delivered, and communication between the client and the moon would never happen.
This release also adds support for using Authorization headers instead of cookies for Eyre authentication, double boot protection fixes and many directed messaging bugfixes.
The most important change of this release is the following:
Urbit provides extremely unusual guarantees for userspace Gall agents. Namely, when you poke or subscribe to a ship it is guaranteed that these actions will eventually be delivered to the ship without a need for the userspace application to have any retry logic. This guarantee is implemented through Ames retrying these pokes or subscriptions every 2 minutes until the ship in question responds. In normal operation all is at it should be, however...
If a ship receives a poke or a subscription for a Gall agent that is not active it will ignore the packet. This design decision enables a kind of reactivity later if the ship does install the agent. But if this ship never installs the agent then the sender is on the hook to send this packet every 2 minutes forever! And even though the receiver ignores the packet it still gets written to disk through the event log. We have seen ships in the wild with a hundred thousand of these "dead flows" firing every two minutes. Most older ships suffer from this issue, and notably there is currently no way to recover from the dead flows other than breaching.
If your ship feels slow the root cause is almost always these dead flows.
410k-1 provides the first layer of mitigation for these dead flows. Every message that has been tried 100 000 times or more will now back off to a day instead of two minutes. We have other mitigations in the pipeline.
This release is on ~zod and is propagating across the network now.
Full release notes at https://github.com/urbit/urbit/releases/tag/410k-1
Reply all
Reply to author
Forward
0 new messages