Tekkadan 🍓 on Nostr: Nested lists enable us to categorize and manage information. The same way I might ...

Nested lists enable us to categorize and manage information. The same way I might categorize a grocery list.

Yes, the possibilities are infinite. You can attempt to reduce trust to some ideal "ratio" or "score" or "level" or "rank," but, you won't find applications that do it on Nostr.

Why would you? These are decentralized, "dumb" relays. They aren't handling computations that require high-end, or expensive infrastructure.

There may be ways of determining trust, but they will inevitably be external to the protocol of Nostr itself. For some communities that integrate or otherwise utilize Nostr, this may be a preferred route for determining specific algorithms, such as a "social Web of Trust."

But right now we are not in the future. We are in the present. You say you "only trust the verified experts of Nostr," to which I would reply, "to what extent are they verified?"

And you could then propose to me, a list of Nostr developers that you are confident in. You may claim to trust them, but there will of course only be a certain degree of trust instilled in any particular user.

For instance, Pablo is a trusted developer because we know he is a lead developer of the Nostr protocol. We trust him to continue fulfilling his role in that regard. Because of his new npub, we also know that he sees himself as an individual and as a representative, and thusly we can also derive that "we can likely trust (see: confidence) Pablo to share information and have discussions about climbing."

Nostr itself is merely a social media layer with integrated support for The Lightning Network.

If we look back to Myspace and Facebook, it is clear that the emergence of social media derives almost entirely from "being able to communicate with people you trust, as well as becoming exposed to people you could potentially trust in the future, as well as sharing information freely between all of the users of the network, despite a plethora of trust networks existing within it; quickly and conveniently."

It is reduced social friction, in a sense.

We are no longer physically bound by information wells and social wells.

I do not need to visit a library to research anything.

I don't need to leave my house to have fulfilling social relationships that span across the globe.

I can even do these things comfortably from anywhere on earth that I regularly visit.

So, this immense wealth of data needs to be categorized and managed. It needs to be accessible from the cloud, to enable multi-device connectivity. And it needs to be secured.

"The internet" is already decentralized, only to an extent.

The extent is "less than Bitcoin" and it is "more than Apple's silicon manufacturing"

The extent is the price you must pay and the people you must trust, to have access to the tools and services that empower you as a user, and as an individual, and as a "subscriber" or "supporter."

The point is- Web 2.0 handles data storage and databasing in quick, effective methods. You can spin up a local server or virtual server at little cost, or at maximum privacy, whatever you need, we probably have more access to it in 2024 than ever before in human history.

Nostr struggles with this, because it aims to be decentralized. We can have a decentralized network of relays, and we can have tons of them because they are very affordable to run.

However, the more complex Nostr becomes, the more demand is placed on relays, which inevitably increases costs (if too much bloat is finalized into Nostr's production).

This means there is no native "databasing" on Nostr. Nostr itself is written on JSON, which stores data in the form of objects.

So, creating a "unique list" as a user means someone is hosting my list (see: relays).

If a databasing application were integrated into the Nostr protocol, things would quickly become even more lopsided than they seem at the moment. People would not be incentivized to host a plethora of "worthless" user data. It would immediately become a "worse Web 2.0"

On the contrary, that is inevitably what Nostr does. It hosts "worthless user data." But it does that because people want it to.

So the question is "how can it effectively act as a database without becoming one?"

And the answer is to enable developers, relays, and users, the ability to create nested lists.

The context is important. Social media clients like Primal deal with a lot of data! But, being able to enable everyone to decide which information is important (NIP-51 lists) as well is which information is relevant (to the application, NIP-32 labels) would empower a means of social authority.

Users of an application have incentive to host relays that allow for specific information (NIP-32). So, to run a network, such as a social media network, it would require users of that network to become relay hosts, to ensure that NIP-32 data is readable, and by extension, the associated NIP-51 lists.

It's hard to put it into context directly because I believe lists are truly the foundation of Nostr.

My best running example at the moment is merely friend lists. The ability to categorize users into groups. You could have groups within groups.

My narrative is that trust is a human inquiry. It is an emotion we derive from investigative efforts. I don't expect Nostr to determine trust for me. I expect Nostr to enable me to determine trust for myself.

Right now the network is a whole lot of unorganized chaos. It's beautiful but it is difficult for both new and experienced users.

I believe that nested lists would enable everyone to manage information better on Nostr. Applications must be responsible for deciding which data is crucial to their networks.

Decentralization empowers networks to operate differently. That is why is is important to directly empower the users of those networks, to ensure they continue to become adopted.

If I could manage my friend lists, feed lists, bookmarks, recipes, and basically any other content related to Nostr natively... Well.. it would be a much brighter ecosystem.

And by extension, there would emerge new methods of discovering trust.

Of course it would be a considerable update, and all existing applications would need to play catch-up in terms of how they apply the new utility. But that is how Nostr works with any change. I hope I am right, because I am greatly looking forward to it.