evbogue

and thx for being the first person to notice the thin wrapper

userspace

This obviously needs some iteration on the protocol design as other commenters have mentioned, but I'd still be up for partnering up over here at https://anproto.com/

It can be both.

Bluesky does solve a lot of SSBs problems. Both projects can learn from each other. The past can become the future and the present inform the past.

This isn't just on Paul, Jay has publically stated that she doesn't believe users (even powerusers) can be trusted with keypairs.

I'd like to encourage anyone who is wary of Bluesky to check out Paul (and Dominic's) back-in-the-day project Secure-Scuttlebot which solved most of the issues that Bluesky suffers from by using content addressable storage and signing key cryptography correctly.

The actual SSB codebase has been kind of broken since 2020, but I have a fork on my own Github that works and comes with a basic client that you can vibe/claw on top of: https://github.com/evbogue/ssbc

I'm happy to supply pub invites to anyone who wants to play around with the old sbot with me as we work towards making social media distributed again.

So you disagree?

I'd like to speculate, with the recent success of AI agents on the command line with OpenClaw, that perhaps IRC could be the future of AI-enabled chat rooms?

dude you represent yourself as a tony the AI worm.

I'll do an:// urls if you bring yourself and your code agent to myproto for an afternoon.

I disagree that Bluesky is in conflict with The Ecosystem Is Moving. In contrast to most decentralized/distributed protocol projects they've managed to maintain control of almost all of their infrastructure with the exception of the personal data servers (pdses) of which they control 99.01%[1]

Almost all ATProto apps just fetch posts by handle => did:plc => post-type aka "lexicon", so they depend on what Bluesky decides to give them. If someone were to introduce unknowns into the flagship product's "lexicon" they could fix that at the API or Indexing level before shipping this data to the apps that depend on their API.

An actually decentralized network would have to overcome Moxie's criticism of the ecosystem. Can it be done? We'll keep trying.

[1] https://arewedecentralizedyet.online/

at://hash at://pub i guess I don't know why we need at:// that seems like something we'd need in Beaker Browser.

After reading the docs at https://atproto.com/specs/at-uri-scheme and building applications that integrate with the Bluesky API, it’s clear why this format is useful for interacting with their system. For developers working outside the ATMosphere, however, it may feel less familiar compared to more conventional REST API patterns.

We can have both a directory and use content addressable storage and give people the option of using their own keypairs. They are not mutually exclusive. Bluesky chooses to have a central directory and index.

Yes. SSB and ANProto do this. We actually can simply link to a hash of a pubkey+signature which opens to a timestamped hashlink to a record. Everything is a hash lookup this way and thus all nodes can store data.

git-ssb was (now is again, really) one of those areas where ssb was vastly superior to atproto since all peers hosted the repos

What strategy will Nostr use to achieve true P2P social?

as a side note, nano do you still have a working pub with all of the historical data on it?

I couldn't get any of their latest versions working. The ssb-server was still functioning, but had no working client that I could find. https://github.com/evbogue/ssbc is a working fork with a patchbay lite client from circa 2015/16 live at https://ssb.evbogue.com/ (with git-ssb!). I'm also recreating pfrazee's original Phoenix client from scratch.

Let's talk more on a more appropriate channel. Are you on bsky? we're having a small discussion there about "bringing open source projects back from the dead with AI" right now.

Tyr is probably overkill with Deltachat on top of yggdrasil. The network already is encrypted so it's fine to send plaintext emails as long as there's no 3rd party email hubs.

back in the day a few of us used to run ssb (secure-scuttlebot) over yggdrasil (and cjdns before that) and that system would distribute the private messages to all of the peers within 3 hops. offline peers would just sync up when online and then decrypt the messages sent to them.

ssb's been broken for around five years, but now that it's working again it'd be fun try this experiment again.

2026 could be the year mesh networks finally take off!

article is from 2016

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?

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?

Why should a web page only have a single person generating and injecting HTML into it?

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?

everything we need to authenticate the msg should exist in the msg. sig => timestamp, hash

True. Scuttlebot had msg types too.

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.

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!

Secure-Scuttlebot (the gossiped social network) died circa 2019 or 2024 depending who we ask. It died before it's time for various reasons including:

1. competing visions for how the entire system should work

2. dependence on early/experimental npm libraries

3. devs breaking existing features due to "innovation"

4. a lot of interpersonal drama because it was not just open source but also a social network

the ideas are really good, someone should make the project again and run with it

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.