How does this handle changes to the website. Is the entire website re-uploaded to a Nostr relay, or is there some re-use of old material that's already been uploaded before?
oh yes, i get that about nostr. my question relates to updating the website.
if i have 5 pages, which i publish to nostr using this tool, and then i make a small change to one of the pages, do i then need to create and publish the entire project again?
it relies on the hash of the contents ex. if you uploaded your website for the first time it get fully uploaded, but incase you have changed some contents lets stay 1 page out of 5, it compares the hash of the assets, and just upload the changed assets, same as the retrieval, unchanged cached contents didn't get retrieved from the relays
There's this newfangled concept called social media where you let other people post content that exists on your web site. You're rarely allowed to post HTML because of the associated issues with sanitizing it. setHTML could help with that.
I just had a flashback to the heyday of MySpace. Now that I think about it though, Neocities has the "social networking" of being able to discover other people's pages and give each other likes and comments.
Much of what is described in the article can be accomplished with content addressable storage.
If we develop an internet where links describe the integrity of a file then we don't have to worry about the content changing out from underneath us. Additionally we get the benefit of being able to distribute the files we depend on anywhere.
Why make a map of hashes that correspond to human readable file urls, when we can directly link to hashes?
Yes, if every single URL in your web application has a hash in it (including <a> hrefs) then you don’t have to worry about anyone maliciously serving a webpage anymore.
But how do you get new app versions? I argue, if you want any meaningful security guarantees, an answer to this question will require transparency and/or code signing (which itself requires transparency, per my comment below)
Both of these systems are rebellions against the structure of secure-scuttlebot, but took different paths as they rebelled.
Beyond using different cryptography, the biggest difference between the "ATProto System" and the "Nostr System" is that Jay Graber wanted to account for deletes and the re-organization of the message structure of an entire feed.
In early ATProto, aka smor-serve, https://github.com/arcalinea/smor-serve Jay didn't like that we couldn't delete a message on SSB so she centralized all of the operations into a "repo" where we can modify our social feed as much as we want, including even backdating posts. We can see how that evolved into how ATProto currently works today by browsing a repo with pdsls.
For Nostr NIP-01 to work, we generate a keypair, sign a message and blast it at a relay. There's no structure at all to how the messages are organized. Messages are out there once they are sent to the relays. This lack of structure leads to all kinds of issues about how one develops a strategy for syncing an entire history of a feed.
Both of these systems have developed into far larger complex systems that are impossible to hold in anyone's mind at this point, but the key difference is being able to delete a message. Most of the complexity in the "ATProto System" results from accounting for a message that one sends and then wants to unsend later. This is why everyone complains that Bluesky is centralized on the AppView/Index layer. But it's also centralized at the PDS layer.
Correct me if I'm wrong but I think another important aspect of AT is Lexicons, i.e. there's an officially suggested way to do schemas, and application authors are encouraged to create and distribute schemas for their apps. Data is grouped in the repo by its schema too.
I tried it twice and the onboarding experience was insurmountable. Never managed to achieve a critical mass of followers or whatever they call it, so things were permanently read-only for me. I'd reply but nobody saw it.
It was a fascinating protocol underneath, but the social follow structure seemed to select strongly for folks who already had a following or something.
Drama has killed the technological progress in open source, if you ask me.
Having seen what goes on in the foss world and what goes on in the large faang-size corporate world, no wonder the corporate world is light-years ahead.
You don't need hierarchy, but you need some sort of process. "Consensus-based" just means that the loudest and most enduring shouters get their way, and when their way fails spectacularly, they leave in a huff (taking their work with them, badmouthing the project, and likely starting a fork that will pull more people out of the project and confuse potential users who just bail on trying either.)
Those people need to be pushed out early and often. That's what voting is for. You need a supermajority to force an end to discussion, and a majority to make a decision. If you hold up the discussion too long with too slim a minority, the majority can fork your faction out of the group. If the end of debate has been forced, and you can't work with the majority, you should leave yourself.
None of this letting the bullies get their way until everything is a disaster, then splitting up anyway stuff.
Hah. Naive take. I especially love this “Those people need to be pushed out early and often. That's what voting is for. You need a supermajority to force an end to discussion, and a majority to make a decision”. We know what needs to be done, but it’s not being done. There’s no consensus. Consensus take time and effort and has a lot of friction. I am part of a coop and I have seen first hand how this goes. And it’s fine, consensus based systems have other advantages, but they move slower that hierarchies.
I can recall a distinct time period where us ssb devs were passing around the url to "The Tyranny of Structurelessness" via local-first encrypted direct messages. The essay helped us understand what was happening but alas we did not have the tools to stop it happening to us!
The core of the issue is that drama is a way to impose your views of the world.
In foss software you quite literally don’t have to agree. You can fork the software and walk your own path. You can even pull changes from the original codebase, most licenses allow that.
Consensus is only necessary if you care about imposing your views of the world onto others.
Massive money moving around the globe to spit out blerg content? It seems over hyped to me. I get it, I can generate some text on my screen, but rarely does it make me anything other than skeptical.
The signed databases can be decentralized, but the index is mostly controlled by Bluesky and most of the 3rd party apps depend on Bluesky API calls. These API calls are not currently applying these tougher filters that the Bluesky social-app applies to the feeds.
