It seems that serving NIP-05 nostr.json with a correct "Access-Control-Allow-Origin" header is not common at all. To the degree that it's not useful at all in web clients to show all the warnings. It's a distraction ritght now.

Maybe we could solve that with DVMs fetching and caching nip-05 data.

It's escalating quickly. 1. They ignore you, 2. They laugh at you, 3. They fight you (we are here)

I'm releasing a relay that is a $HOME for tribes. It is willing to store events for tribe members.

The basic vision is that when newbies join Nostr via a tribe, they get immediate access to a relay that stores their events, therefore act as their home relay. In its current form it's quite similiar to nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6's khatru-pyramid, but implemented with nostr events instead of relay auth.

https://github.com/lez/khatru-tribe

The vision includes blossom servers, NIP-96 media servers, and whatever servers are coming in the future automatically host tribe members' content and provide services to them. The idea is to be able to carry the tribe membership a.k.a. the initial social net between applications. And at the same time provide some defence against the reply guys / gals.

Ideally, there should be also a community UI that provides an initial supporting community for the newbies, which also uses the same relay(s), so it should just work out of the box, without any pre-configuration of relays. They can help navigate the newbies through the rough path that nostr is today. And they can provide the social inspiration to come back every day.

There's a lot more to come in the next few weeks. Some community UI, a tribal knowledge base (wiki) and more. Stay tuned.

nostr:nevent1qvzqqqqqqypzpn7hma38nx3zuwz2f26a4rzqymy8tvge6r68cfckkgxd4jwvrudxqythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qqs0xsgjx7wejaja353tt9s5r5xfsc5fez2j0fx0n68lrfa293tvjtq6v09r7

There is no second best.

Ha raersz 23-an, es pest kornyeken jarsz, szivesen latnank egy btc meetupon. nostr-es demok is lesznek.

A sign that multi-profile ux is not the best.

Great art! Love it.

nice visualization.

I think the 2nd column ("nsite") should be called "nsite host" shouldn't it?

This is good stuff. Onion routing for nostr events.

The amount of privacy this could provide us would cause incurable headache to NSA agents.

https://wikistr.com/onion-routing-nip*fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52

*as* boring likes

I'm happy about it as long as I can choose to display them boring likes.

That is a good question, I can see that you have dig in deeply.

The answer is yes, or no, depending on what you mean by leaving the tribe.

A tribe is basically a multi-level curation of pubkeys by the leader. In this sense you have no control over what tribes you are contributing to.

So lets suppose there is a friendly tribe with good vibes, whose leader is Bob.

And by leader I mean the chief, boss, CEO, alpha, whatever at the top of the hierarchy. Bob has put a lot of work into building a good tribe, and takes responsibility for it.

Then Mr. Troll comes by, creates TrollTribe and stamps Bob. Now the Troll can trick people into believing that all these shiny people belong to TrollTribe.

This is where the other side of the relationship becomes important. There should be a rough consensus among tribe members about who the tribe leader is, and they should state it publicly if possible. Otherwise a tribe cannot act a single cultural entity. By "acknowledging" the leader I meant that members explicitly consented that they want to READ content curated by Bob's tribe and they don't care about attackers who stamped Bob.

This is why forking (as you described) is hard to do, and it's easier to spin off a new tribe, stamp everyone you like and advertise it as a new tribe, already with some content from your sub-tribe.

I don't know if this is what you meant by leaving the tribe :) On the UI "leave tribe" button will probably just remove the acknowledgement of the leader and forget about the tribe. There's no way to control who curates your content anyway.

In quite a few ways it is what it is.

Technically nothing stops them, but in its current form, if any of the sub-tribe members stamp the original leader, member set is back at the original tribe, but with a reorganized hierarchy.

To start a new tribe,

- interference from the old tribe should be minimized

- everyone down the hierarchy should acknowledge the new leader and his rules.

I'm still thinking about ways to make real forks happen technically. If the new leader says "I accept old tribe's stamps up until the fork timestamp, and here is the new context that you have to use in your stamps", then it's possible I guess.

True, not as crisp, but still.... https://www.youtube.com/watch?v=a66aWszVCiI#t=57m50

Oh, I was confused about the large space, I thought it's some outdoors magic. Actually I'm quite relieved that we can't do such presentations to the sky :D

Publishing a new way to organize communities, called Tribes.

Looking for some feedback!

https://github.com/lez/nipls/blob/main/tribe.md

Take a look at my Tribes proposal: https://github.com/lez/nipls/blob/main/tribe.md - it's just been up for feedback

Looks amazing, indeed. And a bit creepy. But, as an engineer, how do you make it? The 3 towers are some kind of projectors here?

I probably didn't find a client library at the time, and implemented it myself (inline) in this repo: https://github.com/lez/nsite