Comparison with other systems

[sanity]

Starting a discussion thread about contrasting Locutus with other systems like IPFS, Bluesky, Nostr, Mastodon, and Matrix. I'll later compile this into a document to go on the website.

[ple1n]

• Fediverse/Matrix
  • Not content-addressed. Uses URLs for everything.
  • Relies on DNS and IP infra
  • Has scalability issues, due to lack of routing protocols. Matrix has full-mesh routing.
  • Has no decentralized reputation system. This (in part) leads to centralization to a few reputatable servers, in Email, Mastodon, Matrix, and defederation drama.
    • Using accounts of some lesser-known servers of Matrix, you can't even DM users from popular servers.
    • Instead of treating Email/Matrix/Mastodon domains as a symbol of reputation, Locutus supports other forms of proof.
• IPFS is a content-addressed distributed immutable data storage system.
  • Locutus is content-addressed, but mutable by design, serving as virtual storage locations with mutable content.
  • IPNS resolves publickeys to respective signed records. It requires periodic republishing of records, which expire shortly.
    • Locutus contracts may replace IPNS by having a contract that only accepts data signed by specific publickey
  • IPFS has native support for DAG. Locutus has interdependent contracts.
  • To have mutable state with IPFS, usually Pubsub is used. It can't validate messages before passing, vulnerable to spam, but it seems they are adding validators.
• Nostr
  • Relays do not interact with each other.

[ple1n]

Decentralization is enforced by design in Locutus

1. All application state that needs replication is stored in Locutus contracts.
2. State is unconditionally verifiable, dictated by its WASM code, independent of any external factors, Ex. where it is received from (which server, which domain/ip), when it is received.
3. As a result of 2, applications have to use publickey cryptography, and even more advanced schemes.
4. Routing is provided, but not a burden (some call routing a drawback of P2P), because it can be turned off or adjusted when necessary.
5. Contracts are automatically distributed, synchronized, verified, load-balanced, served.
6. Able to run over any network, IP, I2P, Cjdns, Yggdrasil, Lokinet, Tor.

I'd emphasize that

• Locutus is a direct competitor to Fediverse.
• CRDTs are not built in Locutus, but you can put CRDTs on it.

[ple1n]

Comparison with existing web3 stack (of cryptocurrency)

1. Front-end, usually distributed by centralized CDN, Cloudflare
2. State query, RPC nodes, gateways and thegraph
3. Blob storage, Filecoin, Storj, Amazon S3
4. Content delivery, IPFS and the services based on it, retrieval market, pinata
5. Anonymity, Nym, Lokinet
6. Identity/PKI/reputation, appliedzkp, on-chain reputation protocols, name registration

What locutus can solve is, the continual distribution of frontend, state query (It's a DHT anyway), and content delivery (It caches content in accord with demand). For many applications, like Matrix, a voluntary, simple network like Locutus is probably enough. (It distributes the frontend with subsequent updates, and hosts the state of rooms).

More accurately it solves the state replication, synchronization, storage problem, in a distributed, verified manner. Alternatives are

1. centralized servers, eg. xmpp server.
2. semi-centralized architecture, federation, ActivityPub, Matrix, usually with centralized CDNs
3. P2P, berty's orbitdb, gundb, zeronet
4. blockchain, with or without IPFS or other offchain storage, rpc/indexing services

Matrix/Fediverse doesn't do state distribution well. It's not hard to find a critique on that. That issue is most critical to the 'final' performance, user experience of a decentralized social platform. Further, the reliance on centralized CDNs, centralization around a few powerful fediverse servers, are not 'healthy'.

Considering Locutus is not a solution to all the problems, I expect apps to compose a stack that fulfills users' needs. Ex. using a light client from some blockchain to allow for more secure name registration. loading videos from IPFS. running Locutus over anonymity networks.

Another example is that if a torrent fails, it's better to get it from a data market, like zkpod which is better than nothing. for most cases data isn't scarce. one can build such a market with UI and state hosted on Locutus.

This is an illustration of a possible future landscape that I agree with. source

I prefer to put dweb protocols into 4 categories, anonymity (i2p/nym), connectivity (cjdns/yggdrasil), state replication (ipfs/locutus/fediverse/torrent/many more), consensus (blockchain). For consensus the extreme is Mina that can offer no state but only a root state hash continually advanced. It also shows that most protocols are just state replication...

[ple1n]

Some (see Nostr's readme, or any fediverse endorsing material) consider P2P bad. It's not true.

1. P2P provides client side verification of data. There is no downside about this, as you can turn off all the DHT routing, seeding, 'noisy things' for your node and go back to the fediverse 'servers being resource donors' model.
   • There is currently no way to verify IPFS data from within a browser, effectively negating IPFS' trustlessness.
2. There is no incentive problem and I'm glad incentive layers are being built. What incentives people to run Fediverse servers ? It's same. The protocol simply tries to introduce server donors and users to each other.
3. It's totally okay to not use P2P when not suitable, but Fediverse is what P2P can solve.
4. Spam, sybil attack is up to how you solve it, how the protocol is designed. Locutus is more resistant to spam due to pervasive verification of data by contracts. Sybil attack can be addressed by, blind-signature-tokens as used in Locutus, or an on-chain registry of nodes.
5. P2P overlays existing networks to be transport agnostic and tolerant to failures (IP/domains being banned or unaccessible/firewalled). It's a core feature that has to be shipped to everyone to be effective.

[ple1n]

Common misconceptions

1. Locutus contracts are not blockchain contracts. There is no transaction fees, or consensus mechanism. It's called contract because machines are executing a common piece of code, and agree on the validity of content (eg. Is that post authentic ? Contract verifies it.)

• Locutus is not a blockchain or has anything built-in about blockchain to begin with. It is free of all of them.

2. I don't need verifiability

• An example of verifiability is, signed posts. With signatures, you can get posts from any server and be sure that the posts are authentic.
• You are stuck to a few servers if posts are not signed. Twitter mirror sites copy twitter's data, but you can't be sure whether the messages are authentic. You are trusting the servers that they didn't tamper with anything.
• On a large scale, It's almost inevitable to require content to be unconditionally verifiable
• Matrix/Mastodon have servers take custody of users' keys. When you post something, the server signs it and pass it around. It's more of an internal thing between servers because you don't necessarily get signatures when retrieving a post. And they don't verify signatures of posts on client-side, which is less secure.
• Self-custody is nice and client-side verification offers maximal decentralization with little overhead. Specifically, the ability to do so. You can always ask some other node to sign posts for you.
• Note: Bluesky servers sign posts, while users have backup keys that can be used to migrate when servers go missing without server cooperating.

3. Pay-for-reputation. It depends on @sanity 's actual implementation. He said donation is not the only way to get reputation blind signatures.

4. Locutus has no privacy/anonymity

• Locutus has better privacy because you can sign your posts and publish through any server to the network. You have to publish through a fixed set of servers on Matrix/Mastodon (usually the one you registered on)
• Anonymity is not implemented in Locutus. Freenet was frowned upon for storing random, sometimes encrypted illegal content in users' computers.You asked for a network without such issue.
• It's always feasible to run Locutus, or access Locutus nodes through anonymity networks, such as Tor. You get full anonymity+privacy here. The only requirement is that your post is correctly signed for example.

5. Fediverse is decentralized

• It is not. In reality, a lot of Matrix users are on matrix.org and Mastodon servers have enormous leverage against their users.
• See atproto's criticism on Activitypub
• As for now (2023/06), you can't even migrate between Matrix servers. You have to register new accounts and lose everything you had. Servers can ban you without prior warning and you lose everything without backup. Servers can deliberately its impersonate users in unencrypted chats.

[ple1n]

More thoughts on comparison between Fediverse and Locutus

1. Fediverse server runners are incentived because they are community leaders. Nodes in Locutus have no such status.

Locutus centers around contracts. If a contract has admin publickeys hardcoded, it's possible for them to attain status. And for this contract to remain available, they need to run nodes.

Reputation/status in Locutus is decoupled from actual servers (addressed by ips and domains). Maybe I can be perceived as a more reputable member if I host a Locutus node.

[TheRook]

Good security engineering is forward thinking, It is about planing on failure. DDoS attacks are more common than ever, and they can be especially damaging for small dapps who lack infrastructure and an ops team. A central problem to nostr is that it lacks censorship resistance via message flooding. In fact many of the projects we are talking about here are not as hardened against DDoS, and in the case of nostr it is trivial to shutdown the entire network with CSRF Flooding, where 3rd party browsers send a flood of requests to evade IP address filtering.

Using Tor as a gateway on the modern network may introduce more problems than it solves. Tor's anonymity makes it impossible for rate-limiting DDoS attacks, and this is being actively exploited. It is very common for Tor hidden node gateways to be held for ransom, and the situation is continuing to degrade as we go into 2023:
https://www.bleepingcomputer.com/news/security/tor-and-i2p-networks-hit-by-wave-of-ongoing-ddos-attacks/

Basically any Tor node can be taken offline at a whim at this point. i2p's DHT on the other hand has a more fundamental flow-rate control for bundled messages which has been more resilient than Tor's opportunistic onion routing.

The i2p's team ability to patch flood-fill routing while they are being attacked is truly admirable:
https://geti2p.net/en/blog/

In terms of operational engineering, the i2p DHT has got to be one of the most resilient out there.

---

Fred did two things very well - it had a good answer to the censorship problem above, and to the pinning economics that come into play for IPFS. I really liked that the more times a freesite was requested, the more capacity was created to deliver that site - which I still think is elegant. I fully agree that forcing people to store unwanted data is undesirable, on the other hand IPFS has the ability to restrict files that your node serves. It allows for users to opt into a network of self-censorship, which is a form of consent that is working and their protocol has gained amazing levels of adoption in the dapp space. And yes there are IPFS nodes which disable censorship because it is just an optional switch. So why not allow people to choose who their censors are?

I think that IPFS would be better off if nodes on the network where more friendly to each-other. Having an agreement where you are expected to cache everything you request - as to not burden the network should be apart of the spec. Additionally - having proxied relays and multiplexed relays that act as a cache for recently requested data. If someone is a gateway without pinning, then they are freeloading off of the network and burdening their neighbors with expensive requests when that could be solved with cheap local storage.

A killer feature for web3 dapps would be to use IPFS's RPC calls but have a "deep pin" feature where these files are held onto for free, similarly to fred but unencrypted. Everyone wants free IPFS pins, and data storage is cheaper than ever. This would help spur adoption in a growing niche.

Honestly the reason why I liked Freenet from the start was the idea that "Never again shall book burning rob from humanity." Well, if Locutus is on Kademlia already, can the node expose this service as an IPFS RPC by default?

[ple1n]

Tor's anonymity makes it impossible for rate-limiting DDoS attacks

Not true. There is Rate-limiting-nullifiers. https://rate-limiting-nullifier.github.io/rln-docs/what_is_rln.html

[TheRook]

In any case, the problem is getting worse. https://www.zdnet.com/article/dark-web-crime-markets-targeted-by-recurring-ddos-attacks/

…

On Sat, Jun 3, 2023, 5:30 PM plein ***@***.***> wrote: Tor's anonymity makes it impossible for rate-limiting DDoS attacks Not true. There is *Rate-limiting-nullifiers*. — Reply to this email directly, view it on GitHub <#619 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7MN2YKXR2W7R5WQECIRDXJPJLNANCNFSM6AAAAAAXYFXTVU> . You are receiving this because you commented.Message ID: ***@***.***>