Ok I've read your message @cel but don't have time to read all the replies here in detail. Here's my take :

1. don't boil the ocean, start simple
   • just hard-code feedIds in a config file on the server which you trust
   • this is good because it requires less new messages, and we can also assume that if a person has access to the (pub) server, then they have the right permission levels
   • we can build some complex permission system later if we need to
2. use tangles
   • so, you and I are both maintaining some install.sh, I want to cut a release at https://installers.scuttlebot.io/git-ssb/install.sh ... how do I do that without colliding? which one wins?
   • so cel starts a new tangle thread with an initial state, then I come in and mutate it. The server decides whether my mutation is valid based on whether I'm in the config file. Actually we can also do access-control as part of the tangle ... I've been working on this with ssb-tangle
   • if we use tangles we can think in terms of a "document" which we can mutate, it also gives us a very clear history
   • fields like { url: link, blob: BlobId, tombstone: { date: UnixTime } }
   • we'd still need a protocol about what to do if there are 2 tangles trying to bind to the same url ...

I notice you're thinking of solutions which fit into ssb-links well, but I guess I feel like that's just using a low level tool and trying to fit the problem into it's constraints. (I'm likely doing the same with tangles!)

1. Pub announce new releases
   • I think the server (pub) should publish a response to setting up serving of the latest blob. I think it would actually be really good / important for it to post a " published" message to acknowledge and announce new state
   • this could be in each a installer tangle, or maybe just a general message, or maybe in an RSS-like tangle which is just announces of all changes it's made to it's state ... this would be nice because if the server needed to be rebuilt it could "replay" itself into the correct state