I don't think Pods are the answer. If they were Mastodon would be everything we wanted. But instead you get quasi locked into someone else's fiefdom.

Nostr has the same issue with relays. It isn't as bad since switching relays is easier, but unless you are running your own you are still at the mercy of someone else's whims.

Whatever comes next needs to be invariant from user to user. At least as invariant as it can be with our network layer. The only logical variation is public addressability under IP. (Blue-tooth mesh networks etc being actually invariant.)

Invariant does not mean equal. Some users will have greater storage, processing power, bandwidth, and faster pings to their contacts. Everyone, however, should own their own data and make their own connections.

The only reasonable definition of "own" is "hosts" but that term has baggage eliciting visions of configuring virtual private servers or docker containers, port forwarding on cheap routers, and all manner of nerdy headaches that only invite attacks.

But all it really means is that your data is physically saved on your devices and can be requested from you by authorized contacts. It doesn't fundementally need to be an active hobby.

Imagine a simplified case with a truly invariant mesh network. Everyone beams neutrinos directly to their personal contacts only. Getting a hold of anyone else would be 5 hops or less. Each user can save their own data to their device and merely notify some people that a reasource is available. Signed permission to request the data. Any unpermissioned request just gets dropped immediately by the first contact you ask to forward the request.

It is an automatic web-of-trust that isolates spam at the point of origin rather than the destination. This allows little people to host from the apps they use without getting overwhelmed.

But we don't have a magic p2p network with the IP protocol. Thus whatever is next isn't how do we give up and find more complicated server-client relationships that protect the clients. It needs to be how do we beat IP into a magic p2p network that works for everyone?

Reply to this note

Please Login to reply.

Discussion

Mastodon doesnt use pods. Which is kind of a shame, because they implemented part of the standard, but not the bit that lets them have pods.

From my POV all the things you say can be done with an "AND" attitude. The prevailing attitude is "OR". We use Nostr OR we use Solid. We use BlueSky OR we use Mastodon.

The OR mentality is great for developers and empire builders. The AND mentality is great for users. I've always thought from a user perspective of building the things I want to use myself. It's a minority view, and you actually get a lot of hate when you have a user perspective. But in the end you get to use a good system, and as a side-effect others do too.

A better solution is "AND". We use nostr npubs AND we use nip-05 addresses. Same with having Nostr to relay and Pods or DBs for storage. Nostr is one of the worst imaginable DBs, but has great properties as a relay.

So the "AND" mentality works really well. Of course few want to admit this, because then they cant say "Nostr fixes this", and all the money that goes with that.

Pods are simply a piece of the internet under your control. Much like a unix file system. It could be on your phone, in the cloud, or on your file system. The glue is in place to include all of this, plus have privacy controls. AND mentality is 100x more powerful than OR. Simply look at what Zuckerberg built in 2 weeks with the LAMP stack. He needed all 4 things for it. Any one on it's would not have been enough.

I might be misunderstanding the Solid protocol (Very likely). Also I mixed up Mastodon and Diaspora. In both cases, however, you are beholden to whoever runs your instance.

I agree, however, that we need a both strategy. I wouldn't get rid of the whole messy TLS/HTTP/TCP/IP + DNS stack. It is a nice way to authenticate and access widely available services. But it is a nightmare of lock in and for identity and personal data. I think we can use the current paradigm to bootstrap something that looks like a magic p2p network.

So, like you suggested, that is exactly what I am building for myself. It doesn't use Nostr and Solid, because I think they have missed the mark. I am probably wrong, but I have the ability if not so much the time, to give it a try.

The worst outcome will be that I end up with a unique way to sync my personal data across my computers at home that no one else uses.

This is very good. So the thing is. If you are able to think creatively and take the BOTH strategy. You can, say, have a nostr key, and an HTTP key, in a COMBINED profile. This allows migration more easily. Just like chaning NIP-05 is easy. Frankly even nostr migration is still terrible. Profiles break all the time between relays. As mine is now. The trick is dont lock yourself into any one solution and take the advantages of all. The Nostr people dont want to talk to activitypub (apart from alex). And the activitypub people dont want to talk to Nostr. But for an end user, having everything is by far the best option. And they dont even need to know the technology behind it. Looking forward to see what you make!

Agree both Solid and Nostr have missed the mark, to a degree. You just want to take the good parts. That is what I will do.

What are you going to use for sync?

Because of the way I am handling communication all files exist as serialized->compressed->encrypted blob identified only by it's blake3 hash. Any info about them is handled by Notifications. Those are single packets of data saying what they are and signing permission to access.

The first use case will be simply communicating with myself. My computers will share notifications of what is available and they can decide whether to transfer the files between them right away or wait till wanted. I'll have to look at caching algorithms to fine-tune where things get stored. I can't just sync and deduplicate since devices may have differing storage capabilities and I'll have to pick what level of redundancy I want. It is very much a work in progress.

At least storing everything with its hash will make deduplication easy. I am just hoping I can get away with fewer than 32 bytes. I have to carefully revisit the security implications. Anything I can save on hash size is a performance win. Premature optimization ftw!

Sounds very smart. I use git alot, which is a hash smaller than 32 bytes.