search

urbit / azimuth

General-purpose PKI on Ethereum
MIT License
134 stars 36 forks source link

Support DelegatedSending invites from arbitrary stars #17

Closed Fang- closed 5 years ago

Fang- commented 5 years ago

Currently, stars can only give invites to their child planets. Since most early adopters (among who many star owners) own/use planets somewhere under ~zod, this makes them unable to send out invites as themselves. Instead, they must manually spawn a planet to whoever they want to give invites to, and only from there build out invite trees.

In this PR, we change the logic in the contract to allow planets receiving invites from any amount of arbitrary stars, rather than just their prefix.

The pools mapping(uint32 => uint16) becomes a mapping(uint32 => mapping(uint16 => uint16)), and we add in both a mapping(uint32 => uint16[]) poolStars and a mapping(uint32 => mapping(uint16 => bool)) poolStarsRegistered to aid in discovering and managing that data respectively.

It remains up to client implementations to discover planets that are eligible for sending. This is a bit more work than it used to be, but isn't the end of the world. I will add functionality for this into azimuth-js soon.

Fang- commented 5 years ago

Neither of the proposed solutions account for the "I'm taking away a planet's invites" case, where the "race condition" would still end up with more consumed invites than desired. But, again,

because these will generally be used in contexts that have non-zero preexisting trust, I don't think it's a problem.

So, agree on leaving this "unsolved".

(Though I guess as a defense, stars could temporarily disable Delegated Sending support (by un-setting their spawn proxy) while they make such changes.)