Why Nostr? What is Njump?
2024-03-26 08:07:00

Tekkadan 🍓 on Nostr: No, of course not. Because Nostr aims to be decentralized by design. **I guess** we ...

This is a long form article, you can read it in https://habla.news/a/naddr1qqxnzde3xy6rxvp3xgenywfjqgs9pqy620l0jkgy2yaggr2qs25jk3wdtudeusmdn54e92yuuzglzeqrqsqqqa28zh65tg

No, of course not. Because Nostr aims to be decentralized by design.

I guess we could but unless it serves people, then it defeats the point.

So are we building a “Web of Trust?”

No, we’re building “decentralized Webs of Trust!”

Okay..? Let’s talk about Trust.

Quoted content derived from “Trust is an Emergent Property of Effective Networks”:

Our dominant form of economic transactions are not really designed to optimize trust

@Tony): BROKEN MONEY.

The reason is simple:

Trust is not a market transaction, it’s a human transaction. People don’t work by supply and demand, they work by karmic reciprocity. In markets, if I trust you, I’m a sucker and you take advantage of me. In relationships, if I trust you, you trust me, and we get along. We live up or down to others’ expectations of us.

Note: While this article makes a poor analogy when it says

In relationships, if I trust you, you trust me, and we get along

its point remains valid. In relationships, people are incentivized to trust, because it is natural to distribute and derive value from our individually-established “trust networks”. “Peer-to-peer relationships” move at the slowest pace, relative to other forms of networks. Like Nostr! So, while the highest realms of valuable, responsive connectivity dictate the current environment, all forms of networks are subjective to the same level of karmic reciprocity.

If you want to say, “Nostr’s decentralized aspect actually establishes faster P2P networks than ever possible,” I’d agree with you! GOOD JOB! We are improving our foundation. Blessings.

We currently organize around Tribal models

ALSO PROPOSED BY @DavidStrayhorn: https://pgf.tech/

plus Institutions, plus Markets.

In the 21st century, Networks are becoming the next dominant organizing model, as explained by David Ronfeldt in this diagram:

TIMN

As the Network organizational model comes to dominance, I think we will see a return to trust as a lubricant of social and economic exchanges.

Trust is an emergent property of effective networks.

Trust emerges from effective networks

If trust is a sign of healthy networks then, as Charles Green says, we are teaching the wrong things at school and at work:

Our public education and culture is loaded with the free-market versions of trust. We teach, “If you’re not careful they will screw you.” We passcode-protect everything. We are taught to suspect the worst of everyone, be wary of every open bottle of soda, watch out for ingredients on any bottle.

Then in business school, we are taught that if customers don’t trust you, you need to convince them you are trustworthy – partly by insisting on our trustworthiness. You can’t protest enough for that to work: in fact, guess the Two Most Trust-Destroying Words You Can Say.

I have noted that there is significant difference between cooperation and collaboration, with the former often overlooked in the workplace. Collaboration works well when the rules (like markets) are clear, and we know who we are working with (suppliers, partners, customers). However, in networks, someone may be our supplier one day and our customer the next. Cooperation is a better behavioural norm because it strengthens the entire network, not just an individual node. Cooperation is also a major factor in personal knowledge management, for we each need to share and trust, as our part of the social business (learning) contract.

collab-coop

In the network era, trust will become much more important, and it is not something that, once lost, we may be able to regain in a world where the network remembers everything, for a very long time. It truly is becoming a global village, for better and for worse. Trust should be taught, discussed, promoted, and practiced, in schools and in business.

So, let’s talk about Nostr.

Trust on Nostr. Does it mean anything? Should it mean anything? I certainly don’t “trust” the users of Nostr any more than I can throw them. Meaning: Not at all! Sorry not sorry! I don’t know you! If you follow me on Nostr, you have likely never met me, and you possibly never will. That’s okay! We can still influence each others’ lives!

But how?

We stop chasing “trust.” Instead we chase confidence!

We pursue organization and user-authority!

We pursue verification!

We pursue context!

We pursue value!

We pursue.. well.. all of those things we deem valuable and important and influential. Everyone is accepted, everyone is valid. Because that’s how decentralization works, and that’s how Nostr works. That’s how Bitcoin works.

Okay, but really, how?

Take a long, hard look at NIP-51. What’s missing? Structure. Where is structure derived? Nostr applications, and users.

Listr can show me my lists,

and so can Coracle,

and so can Nostree,

and so can Highlighter….

But do they provide value by allowing me to create, edit, and view lists, if they don’t allow me to manage them?

NO.

(Okay, yes, but only to a certain degree.)

From a user standpoint, they generally don’t offer enough value.

Nostr lists do not enable users to categorize information contained within those lists.

“Get to the point already.”

Well, we can’t really employ databases on the Nostr protocol. That isn’t decentralized.

But we have the elements of a decentralized database. We can create labels that are unique to any particular namespace (application), with NIP-32. @hodlbod This allows for unique relationships between applications and lists.

We can create lists, and sets of lists, with NIP-51 and kind 30000.

What we can’t create is nested kind 30000 lists.

This is essentially the foundation of a unique, decentralized database. It is modular matrices within a modular, decentralized network of categorized lists, that can be aligned at will by clients/applications!

How wonderful is that?!

It would enable people to categorize their bookmarks. But, to what avail? Are they going to manage every link they ever save over Nostr? Maybe, if their relays accept the amount they choose to archive (see: cost, practicality).

What it would enable, or further empower, is application-relay relationships. Users of a particular application that hosts “user data” would need to support the network by hosting enough relays to keep costs low, and to keep the application maintained. This is a positive feedback loop.

More importantly, it would allow native handling of all kinds of things. “Friend groups” and “lists” and all sorts of imaginable structures.

Even MORE IMPORTANTLY, it would enable applications to catalogue their collections of information native to Nostr.

Let’s say I want to implement an imageboard with support for Nostr. In this example, an “entirely anonymous BBS application” would be deriving npubs from relays, and signing comments to a central, decaying database. No notes would be passed via Nostr, unless users “discover” each other through the platform, and choose to “follow” each other on Nostr, and communicate through native means.

How do I decide which “boards” exist? (see: topics, channels, communities)

You can’t without empowering people with nested lists! You need the ability to manage lists within lists.

Then you need the ability to employ labels amongst that local catalogue. (see: NIP-32)

Then a specific kind, 5000x, that implements “nested sets of NIP-31 label lists,” for unique collections amongst applications that can be further refined and established by…..

DCoSL! @DavidStrayhorn

https://github.com/wds4/DCoSL

We can opt to employ social graphs locally! We don’t need to build Web of Trust on Nostr. We just need to employ it!

We don’t need databases on Nostr. We just need to employ Nostr in a way that acts as a rudimentary database!

Please, @Pablof7z, set us free.

Gladly accepting feedback. My dm’s are always open (and encrypted, thank you Nostr!)

Author Public Key
npub12zqf55l7l9vsg5f6ssx5pq4f9dzu6hcmnepkm8ftj25fecy379jqkq99h8