Fight Club

Big Trouble in Little China

The Fifth Element

Thanks, this is exactly what I’ve been thinking about as I’ve become more familiar with Fediverse protocols and applications.

MapReduce is term pertaining to a software data retrieval architecture/process (also known as divide-and-conquer). The simple version is that instead of asking one super big database that knows “everything” you ask multiple smaller databases the same question i.e. “what all posts do you have from bob@domain.com?” (this is “mapping” a query to mutliple sources) and each database returns 0 or more results, then the query interface joins the results together (“reduce”) to a single response. This is common in “big data” because you can more efficiently optimize the query by parallelizing it across many machines/workers/nodes. There are additional optimizations that can be implemented such as caching common queries or data-sharding (items a-f on node 1, items g - k on node 2…).

I don’t think Nostr protocol is immune to the development of big centralized popular instances. Especially if something like Threads integrates and becomes the “default” client with millions of users over night. Users, in general, will always gravitate towards content and community. But, I think Nostr has a slight edge over ActivityPub in handling that problem by the user having no direct dependence on any one particular host.

I’ll have to read more into the Nostr protocol specifically as it pertains to privacy, tracking and content injection (ads).

I’m by no means an authority on ActivityPub nor Nostr, I apologize if that may have been surmised. I too am just chatting.

I don’t know about the community. But from a protocol standpoint I think Nostr might actually be technically better.

At a high level, ActivityPub (and it’s implementations) imply there are many servers and to operate in a federated way, each server needs bidirectional communication. This is results in a exponential increase in traffic between servers and storage requirements. There’s also no requirements to identity so it’s up to implementations and currently that leads to many duplicate accounts.

Whereas, at a high level Nostr is a client and relay system. Your identity is constructed by public/private cryptographic keys (instead of as fractured identities registered on various different servers).

This is similar to email cryptographic signatures and also most blockchain implementations. Then content/posts are sent out to any number of message relays. Consumers of the content/posts do a map-reduce query against multiple relays to find content.

The benefits here is that if the relays go down, your identity is still safe as it’s manifested by your keys. This also means that there’s slightly less incentive for big centralized server dominance. Another benefit is that you don’t need bidirectional communication across all (most) relays thus reducing traffic and storage costs as the system scales.

With all that said. I have no idea what Nostr looks like in practice or what the community health looks like. Or what community moderation tools exist. But from a theoretical standpoint it’s a much more scalable architecture.

Lemon Meringue with warm cream poured over.

I can’t say what it should be. I’d argue that each Content Instance should have it’s own path to becoming trusted. An example could be: demonstrating quality post/comment content during the quarantine period.

Anonymity/Privacy are not inherently universal. Your true identity can be known to some and unknown to others in this case masked via an alias.

Thus, I propose a hypothetical arrangement: separating Content Instances and Identity Instances.

Content Instances host the main communities and discussions. There must still be “many” (hundreds maybe even thousands) of these so that none can wield power of the others.

Within Identity Instances you are known or at least verified and vetted. External to the Identity Instance a user is only known as their alias from the identity instance. There should be many more of these with a maximum user size ~100 (see Dunbar’s number).

Further, federation should not be open by default. New Identity Instances are quarantined initially with the ability to subscribe to communities on Content Instances, but the posts and comments from the Identity Instances are not federated back to the Content Instances.

The goal here is to employ a heavily distributed Divide & Conquer approach to moderation and community management. The users of an Identity Instance are responsible to one another as any of their actions may cause the entire Instance’s users to be affected (i.e. defederation). Even better if you know each other, you should feel some real social pressure that your actions online will impact your social life IRL.

But to be honest and pragmatic, I don’t think this will form organically nor do I think it could be enforced. And even in practice it probably wouldn’t work. But perhaps it’s a nice dream.