I really like the approach that @christianbundy outlines with 1 subdomain per feed. That leaves the problem of what the "official" git-ssb install.sh should be.

I'm really keen on some sort of system where blobs are verified by other users on the system. And once a certain threshold is reached, the server will switch to the new version. This has multiple benefits. One is that its much harder to attack. Secondly the verified could mean that they ran some tests or something else, in this case it would be a way to go from rc to final.

I have been thinking of a similar idea for blobs that contain the latest state of a number of feeds for the browser system I'm working on.

@arj

I have been thinking of a similar idea for blobs that contain the latest state of a number of feeds for the browser system I’m working on.

Would love if you could expand on this. I've been thinking that it would be nice if we posted a branch-like list of the latest messages from each feed we're aware of. This would make it easier to sort messages based on the order that they propagated around the network without relying on timestamps.

Is that what you're talking about, or something different?

@Christian Bundy what I was thinking about is blobs that contain aggregated states which will allow nodes to consume messages without necessarily having to keep the full log. So imagine I want the latest name, image and id for some feeds. I look for messages of say type feedAggregate + all the messages linking to this message. A message of type feedAggregate would link to a blob with a dict of the state of feeds + whatever information is relevant, such as how the blob was produced. And the messages linked could been social proof that the message is correct, or at does not contradict their world view. These message could even link to a script that was used to verify the blob. The same could be true for gatherings or books or whatever type you come up with. So it acts as a snapshot or pre-computed index.