your relay list (at least on relay.damus.io has no tags). maybe it was wiped by a client you used. I assumed you did this on purpose.
I agree about not blasting everything. But blasting relay lists helps clients find notes. Perhaps its better to just send them to a broader set of relays.
Relay lists yes, I agree. But relays that do git things? I don't think my git repos should necessarily be in the same place as publish notes about random topics. Maybe we should have a special kind for "lists of recommended relays that do git things" like we have for "lists of recommended relays that do wiki things". What do you think? We just add that to NIP-51.
So you can figure out my outbox relays, fetch my recommended lists of relays that do git things (which may gives us a nice way to discover other git repos from other people while also having some spam-filtering in place) and search for my repos in those.
the git repo announcement event (30617) is a small and infrequently updated event designed for discoverability. It should live on relays that store pubkeys relay lists and metadata.
Its less overhead for relays and clients than if we designed such that each repo had its own pubkey.
What happens if the the top 5 big relays censor anyone publishing events with Bitcoin code in it?
There will be some types of relays that just archive everything
more relays
How do you discover these relays automatically?
There has been tall about putting "accepted kinds" into NIP-11, which would be the first step to making these relays discoverable if I understand the problem correctly.
Updated answer: NIP-22 via NIP-66
See `k` tag in `30166` event.
What do you mean by in it? These events just have metadata about where to find the code and are used as the root event to reply to with issues and patches.
Are you suggesting these will be censored? If they were, wouldn't the maintainers npubs also be sensored along with their NIP-51 git relay lists that you were suggesting?
Clients could follow the huluristics about where they might find events from those users and look for the announcement events there.
Is this a terrible idea?
```
{
"kind": 10002,
"tags": [
["r", "wss://expensive-relay.example2.com", "write"],
["r", "wss://git.fiatjaf.com", "git"]
],
}
```
Guess we could argue to also have this for nutsack wallets, DM-s and others?
Or just use nip51
Good point. and blossom. I would actually prefer this to reduce the number of events we need to ask for and manage but I'm pretty sure you meant this as a counter argument.
You know how people in bitcoin talk about month long detailed discussions about new approaches to something and then up realising that greg maxwell suggested a better approach 10 years ago? I feel that way about fiatjaf sometimes.
On second thought nip51 might be an overkill. We have to fundamentally rely on ppl not deleting their kind 10002 relays from the whole network.
If you have those redundantly disseminated then you just query those and then the announcement events for repos, wallets, blossom servers etc. with the relay hints if applicable.
Yes, better have a new kind 10017 or something like that with just the git relays -- but having a way to recommend other git relays in it wouldn't be bad.
In any case, I think for now just having the relay as a hint in the naddr or "a" tag reference is probably enough.
