SMALL vs big World Design

[SionoiS]

I’ve been thinking a lot about the Waku service marketplace. Something has been bugging me greatly. It seams we have 2 very different designs coexisting.

In social media terms, there is 2 types of design called big and small world. Small world social media was the first. IRC, MSN messenger and early Facebook are all small world social media. Now contrast this with Tiktok, Instagram and X. The latest and greatest in big world design.

Very different experiences wouldn’t you agree? What is it specifically that makes them so different and why does it matter to us designing a service marketplace?

It matters because Waku is a communication technology for human beings. Even if we don’t transmit cat pics and memes like social media, how people communicate will be shaped by our design decisions.

Small World

I think the main characteristic of small world design is localism. The entire design is centered around the user. What I mean by that is without the user’s perspective this cyberspace cannot be experienced. What does Facebook from 2010 looks like to a non-user, or a user with no friends?

The Facebook I remember is me and my high school friends sharing low-res video of us doing stupid shit for laughs.

The tech by design (or not) was putting the spotlight on us. Each of us a universe, in aggregate a multiverse of social bonds.

Big World

Algorithmic feeds were a turning point. The focal point shifted to what is outside, we all became spectators. How could your friend’s funny video compete with the absolute funniest the internet had to offer?

Being exposed to so much information is both good and bad. Unrealistic beauty standards or inspirational greatness, tailor made eco-chamber or opposing opinions, real and fake conspiracy theories, connect with like-minded individuals or be harassed by ass-holes, the list goes on…

Waku service marketplace through this lens

I’m not sure if my descriptions are balanced but I do not think one is better than the other. I just want to make sure we know in which category our design will end up.

Must a service provider share a community with you (even if anonymous)?
Should providers be interchangeable?
What are we optimizing for; user, app, provider or the community?
Big worlds must be searchable, small worlds are discovered.
Big worlds needs explicit reputation, in a small world it’s implicit.

Every design decisions we will make fall somewhere on this spectrum.

WDYT?

[haelius]

Thanks for this framing.

I’m certainly in the camp of believing in a “small world” approach (at least for the foreseeable future) in how we frame service incentivisation.

In fact, your post helps us clarify that we’re developing tools to be used first of all within a tribe (avoiding the ambiguous “community” here) for members of that tribe, who already have a stake in the “health” of that tribe, to contribute by provisioning services and get some compensation for doign that. The difference here with “big world” design is that there’s always an intrinsic incentivisation present too. Tribe could be any group with some shared interest that coordinate using Waku, whether it’s users of a specific app, members of an actual or Stauts community, etc.

[fryorcraken]

For any problem we need to solve, it is fine to state specific limitations, or context, we are solving within. Aka, starting with a more specialized options that makes a number of assumptions, or state a number of limitations.

As a first version is done and worked, we can iterate on by remove limitations.
This is where talking to the user then comes handy: “here are the limitations of the product, which ones are most problematic to you”?

The difficult part is ensuring that the initial design is modular and extensible enough, so that removing a limitations does not lead to a ground up redesign. But only a rewrite/redesign of a specific component/module.

In our case, the reason why we want to stay away from federated designs is for privacy and censorship-resistance purposes.
This is why we pushed back against a “one community per shard design”, because it does not give user participation anonymity, it has poor censorship-resistance when boostraping a community and doesn’t scale.

Another recent example is how we proposed for “autosharding of 1 shard” to be default value for Waku SDKs (when not using TWN). Because it does not lock in the design in a static sharding, and while being basically the same as static sharding, it does open the road to later increase number of shards and “only” change the generation in message content topics: a path to scalability.

Hence, when looking at the service incentivization model, it is fine to keep items out of scope, and state limitations - look how most Waku specs does not include protection against active attackers - as long as we don’t lock ourself in a way that we cannot lift the limitations that matter.

I know we are pending a first architecture proposal. Once we have it, it’ll be easier to talk about what compromised we can roll with, and which one should be considered from day 1.

---

Back to the small vs big world. IMO, every big world to be a composition of small worlds. It is a question of clearly identifying what are those small world, so scalability, privacy, security and censorship-resistance can be correctly assessed.