Users do not need to register new accounts.

Yes, we know publickeys. From a practical perspective, a network with no registration is vulnerable to sybil attacks and spam, which is contradictory with other points. Session doesn't need registration, and offers reasonable functionalities, because it has a blockchain service node system, which is robust on its own. Here I refer to registration as metadata. Locutus has a blind-signature registration system which is required for anything resource-intensive. For IPFS and torrent, their goal is an immutable store which is not the same as a social media.

We do not have servers to store users' data.

This is indicates the architecture of full P2P. It introduces a lot of problems. How can they communicate easily then. And it conflicts with 'access data on new devices easily'.

Nobody can access or censor users' data, not even us.

P2P networks are naturally public and accessible. Censorship still applies, unless active measures have been taken, eg. usage onion-routing.

Nobody can shut down our service unless they shut down the whole internet.

Then I assume it uses neural linguistic steganography. Look at China, Russia and Iran. Many networks can't even pass Chinese GFW. That is an extraordinary claim

This is exactly what makes me feel sad.

Matrix is a good example of what social media should look like, and how the information flow. People should have the right to communicate with each other with their own tools and channels. But now we live on different islands and were totally dominated by the landlord, we don't own our property which is data, and don't have the ship to go to other islands.

Matrix is a good solution, and so does Mastodon, but regular people don't want to use it at all, it never became popular.

And this is exactly something we want to change, not just because we could have a better solution, but also have the potential to go viral.

"Look at China, Russia, and Iran. Many networks can't even pass Chinese GFW. That is an extraordinary claim"

Actually, I always use these three countries as examples to explain what makes us special, cuz most people can only understand e2ee at most, but even Signal or WhatsApp can be easily blocked if the gov controls the ISP. It's a weakness of all centralized social media and a large amount of other decentralized social media.

I researched these"new solutions" again, but I have to say, we had a lot of other P2P protocols already, but all the other P2P can't fix one major issue: what will happen if the receiver is offline? If it's pure P2P, where to store the data? Yes, we don't have this kind of issue for voice or video calls, but we still massively rely on text and messages.

And for all "new solutions", the problem is not even about the technical side but marketing. How to convince people to use a better new solution? Pay ads on Facebook or other places? Can they make enough money back? That's not financially reasonable.

We're a very special P2P solution that could solve the above issue at the same time. Technical and financially reasonable.

what will happen if the receiver is offline

No, I am not an advocate for pure P2P. And new solutions tend to be less P2P-ish.

Locutus stores data in contracts served by the network, even for one user's inbox.

They can decrypt or disable it

Why ? We are writing our own clients and protocols. It can't be disabled.

nostr is not p2p but p2p capable, you do own your data in the case of both nostr and holepunch keet, the offline use case is quite pointless tho for social as you cant really do anything without a network connection

you have a very difficult challenge trying to pull people away, facebooks network effect is its main asset and only something like a twitter with a reasonable size network could challenge it and why elon is likely buying it or not

i have watched small communities move off big tech and when they federate they can magnify the effect, that strategy is really the only thing working currently, signal also got traction which basically is family and friends running another app so a not too difficult effort

the main point i think is the thing actually works, the amount of little bugs signal had fir years is enough to throw any normal user

from what i have seen is these things get toooo complicated and dev effort gets wasted filling many useless features when fundamentally they dont work

there is some really cool ideas to build a better product, big tech has missed some rather obvious things but you cant go past what is already proven as so many things also fail for some rather wacky ideas

if you have a compelling product you can pull much of the fediverse over, thing is i have deep doubts you do have a compelling product, literally no one yet has been able to do it, matrix could easily do forums and chat in the same app but they have only implemented a disfunctional version of threads and so they miss those users

I’m confused. All e2ee is done through the client side. If I write a client and install it on my iPhone whereby I encrypt data and send it to you along with a key via some type of key exchange mechanism, no intermediary can read it. That’s the point…..

Or have I misunderstood you altogether?

No, this is not a bug or dysfunction, this is a feature.

you should worry more about what will happen to Signal next, just like what happened to WhatsApp.

If it's fundamentally impossible, someday, someone will do it in some way.

There are two key components, one is the way to encrypt your data, and the other one, and even more important one is, where is your data, if your data still need to go thru their server, there is no 100% safety. That's why Bluesky and us want to build our non-blockchain-based decentralized social media protocol, but we chose a different path.

Because you are not the owner of the platform. And Mark Zuckerberg or someone else is.

But you are right, It’s not at the whim of some company operating servers, so, the solution should be "serverless".

In the case of closed source like WhatsApp, sure - absolutely - I’m not Zuckerberg, I can’t fix it. In the case of open source like signal etc, I still can’t see why we can’t engineer it out…..

I’m very supportive of it being serverless 😊. I just read one of your earlier posts as ‘someone else operates the servers so e2ee is useless’. I may have just misunderstood you.

1 "$fallback": "This post includes a poll which your app can't render.",

brh

Are there any working examples of AT Protocol being used‽ ActivityPub is being used by millions of people already, ranging from individuals, businesses & even governments.

I know AT Protocol is still in beta, but there should be examples of its use somewhere.

I think I understand what you are saying. ActivityPub users can communicate with each other on different instances, but migrating between different types of instances is very difficult.

I am on Mastodon which allows me to communicate with anyone on Mastodon, Pixelfed, WriteFreely, Peertube, FunkWhale, etcetera.

However if I wanted to move my Mastodon account to Pixelfed it would be very difficult. I can easily move from one Mastodon account to another Mastodon account, but not from Mastodon account to a Peertube account.

Is that what you were conveying‽

hey is there a place for threaded specific questions? I haven't had a chance to scroll up thru all the chat here, i have some really basic questions -

are the @names existing dns names or new names using XRPC? If they are new names, who are the registrars and how do they timeout?

Indexing is sorting so a map reduce operation can build an index. In fact Google uses distributed systems running map reduce to build the index.
The question is how do we alter the process from crash fault tolerant systems we use today to a Byzantine fault tolerant system if mutually distrusting indexers.

This could be done with redundancy. Coldest N servers in the DHT all store the index chunk client queries K of N indexers and if they don't match declare the minority report to be an error.

This is pretty inefficient so it's worth continuing research into the use of ZKP to make a provable sort.
I would talk to Dan Boneh https://crypto.stanford.edu/~dabo/ if you want to collaborate on building an efficient proof based decentralized index.

so i just discovered the at protocol via a mention in matrix live and i'm not super sure where to give feedback about it, i figured i'd join here and talk about my thoughts reading the documentation.

first of all, things i liked:

• i think it's good to have focus on decentralized identity. a big pain point in current federated social software is being reliant on the server you signed up on, which gives server admins much more power than regular users. matrix's approach with rooms being the core data structure does help, since server admins don't directly control the rooms (they're replicated and synchronized via auth rules in the room itself)
• this uses replicated data structures as well, but the basic data structure seems to be fully user controlled content stores, which i think is appropriate for social media where you're mostly authoring your own outgoing messages and there's not much overlap with other peoples' messages. on matrix i think it's more important that everyone see the same view of the room vs a user having sole agency over their content

things i don't like:

• schemas. i think this is a bad way of doing extensibility and will suffer greatly from xmpp-itis, where different software implements different extensions and interoperability is a guessing game. the big thing matrix does here is it uses the same protocol stuff for everything. there's no thirdroom specific things the server needs to know about. it's just events in a room; the server knows how to deal with events in a room! activitypub sort of has this generic thing going with activity types and all, it would be possible to create a fully generic activitypub server and use activitypub c2s for that. the big issue with that ofc is it lacks server side aggregation, so it wouldn't be suitable for anything at scale. i think the best approach here is to have the core protocol include everything you need for any client, in a generic and flexible way (matrix has a generic concept of event relations which can be used for aggregations), and the client itself is the only thing that really deals with extensibility and unknown message types.

• Self-verifying immutable state
  • IPFS (or less ideally torrent)
• Self-verifying mutable state store
  • Freenet/Locutus (or less ideally Matrix)
• Self-verifying authentication
  • Publickey crypto / MAC
• Self-verifying consistency
  • Blockchain (a mutable state store too)
• Self-verifying computation
  • ZKP

leave it on the user to choose how they want to do it.

Not how it works. If you leave it out users would choose something unideal, competing solutions, incompatible protocols. This is a fundamental requirement of modern IM.