A way for relays to be honest about their algos

[securitybrahh]

this PR introduces NIP-41, a way for relays to be honest about their algos, edits 01.md to account for changes in limit (related #78, #1434, received_at?, #620, #1645) when algo is provided, appends 11.md for relays to advertize whether they are an aggregator or not and their provided algos.

solves #522, supersedes #579

I think about this a lot - In other words, the only vocabulary in the system is that of a pubkey.

The algo url spec can be described further, kindly give your recommendations. e.g. wss://some.relay.com/.algo/zaprank?name0=arg0&name1=arg1

There maybe some grammaritical/lang errors, kindly suggest any changes.

[securitybrahh]

Give people a choice to what algorithm they want to use. - Jack Dorsey

Giving clients and users (pubkey) agency over what algos they want to subscribe to, needs relays to be honest about their provided algos (note even closed source algos' intention can be communicated honestly by a relay)

[luigi1256]

there is literally only one relay algorithm on nostr, too soon

[securitybrahh]

only one relay algorithm on nostr

How so? I have seen "trending", "hot", "recent", "random", "top" etc coined here and there.

ppl using pow, zaps, mutes, likes, etc for algo signals.

too soon

considering you need clients to support this, mendation of NIP-41, breaking changes & backward compatibility etc I don't think so.

[luigi1256]

I was referring to https://algo.utxo.one/ which claims to be the "first algorithmic relay", I don't know in which relay you saw these things?

[staab]

I don't think this is a good idea. Classification nomenclature is a never-ending can of worms, creates a ton of work for clients, and doesn't ultimately solve anything. Different relays should be differentiated by being used in different ways. It wouldn't make sense to add algo.utxo.one as an inbox relay for example, but if you did, clients would have to try to use it that way, regardless of whether the nip11 advertises a different ordering. I think this functionality might make more sense in NIP 66, which is more for discovering relays that might work for a particular purpose than dictating client expectations.

[vitorpamplona]

It's best if each algo is a separate relay and we don't change the interface with clients.

Users can just add the new relay as a feed with just that relay and without the client reordering the events from upstream.

It's a feature for the client to code though. Usually, Nostr clients have to assemble events from multiple relays and that requires clients to sort them against each other, which breaks the results of any algo relay.

[securitybrahh]

Usually, Nostr clients have to assemble events from multiple relays and that requires clients to sort them against each other, which breaks the results of any algo relay.

good point! related - #1268

Different relays should be differentiated by being used in different ways.

good point!, related - Relay Type Nomenclature (moderating agggregating ralay?)

[securitybrahh]

It's best if each algo is a separate relay and we don't change the interface with clients.

not sure about that, as relays rn are aggregators too (i think we have to add relay type something in NIP-66.md)

It wouldn't make sense to add algo.utxo.one as an inbox relay for example, but if you did, clients would have to try to use it that way, regardless of whether the nip11 advertises a different ordering.

yeah I think the proposed NIP-41 probably needs to be appended to NIP-66 somehow (if possible/desired) rather than being a standalone.

I think this functionality might make more sense in NIP 66, which is more for discovering relays that might work for a particular purpose than dictating client expectations.

My main intention behind this PR, is to find a way, to make relays honest about the order in which they provide the events, but yeah a client subscribes to multiple relays, so the interface itself need a reciprocal change as well.

[securitybrahh]

Relevent :

"ATProto Feed Generator Starter Kit"

https://github.com/bluesky-social/feed-generator