NIP-74 (Portability of Client-side Sorting/Filtering Algorithm)

[louhutchinson]

Attempting to add portability of client-side sorting/filtering requests in standard format enabling migrating personal algorithm from client to client.

[vitorpamplona]

Can we try to merge this idea with https://wikifreedia.xyz/cip-01/97c70a44366a6535c1

@staab

[louhutchinson]

@staab
I think there could be a merging of the ideas. I look at the proposal I drafted as a "simple sort/filter" while the idea you have brought to my attention represents complex or sophisticated sorting/filtering. The purpose is to define portable settings that a user could click options on a tab in either Damus or Primal and would carry through both platforms (and future/other NOSTR clients). I find unions, intersetions, and diffs to be more sophisticated than what I've proposed. Since I dont see an actual PR for that idea, I can reach out to the poster of that wiki and see what thoughts he has for inclusion or whether he would like to make a separate proposal.

[louhutchinson]

I've reached out to @hodlbod for comment. I've also cleaned up and implemented Asai's suggestions. Please let me know if any further work is needed. Eager to help.

[AsaiToshiya]

FYI, Staab's Custom Feeds is what is called the NUD.

[staab]

I don't think this is realistically very useful. I carefully excluded from my NUD concerns like sorting, reaction thresholds, language, etc. because they can't be implemented by the average client. Passing around a data structure that requires indexing social signal, identifying promoted content, and content analysis requires everyone who wants to use it to rely implicitly on centralized services. This is contrary to the nostr ethos of decentralization and thick client/thin server.

The way I handled more advanced use cases in my NUD is by including relay and DVM selections to be included in feeds. This allows a spectrum of tradeoffs between centralization and control. In other words, if you want an extremely custom feed, you can do literally anything you want just by pointing to a relay, including stateful pagination and user-oriented content curation. This is centralized, but explicitly so, because you're pointing to a particular url, making the trade-offs of trusting a service clear to the end user.

This NIP could potentially be used to allow relays or DVMs to describe and advertise their algorithms, but we're pretty far from having anything like that, and something more idiomatic would probably be better (all the filters in this NIP have to be interpreted in order to be applicable to actual nostr events, as opposed to nostr-native filters, which have much clearer semantics).

[louhutchinson]

The first paragraph is contradictory within itself. Assuming you've accurately captured the "nostr ethos" of thick-client/thin-server. Then what I have proposed is extremely useful:

• The client would be responsible for sorting/filtering based on the contract it has saved as an event on the relays making it both portable and durable.
• The relay would be "out of ethos" in that any sorting outside of timestamp or SLA would constitute a form of censorship. We're going to leave SLA out for now because (again) the whole point is portability and relay independence sponsoring thin-server/thick-client.

Which brings us to your second paragraph. Your idea as you have explained it in this paragraph depends on relay-pinning. If that isn't antithetical to the nostr ethos, I'm newer here than I thought.

Third paragraph. Since portability is key, with very modest modification, there are many permutations that would allow for a hosting relay to sort/filter based on stored algo settings.

• A portable sorting event could be consumed/enforced by hosting relays. This could still live/work with .content protected. <===literally a revenue stream for relays (but then pinning, yuck)
• The sorting events could be plaintext (being viewable would/could look like a PII fingerprint but whatevs) and consumable/enforcable across all relays that want to participate. Service to others... a novel concept.

Lastly, this is an "implementation possibility" the contract is in the kind. The implementation is on the client (which is where it should be IMHO). The server's (relays) could do it for a buck but all of it requires a published contract and strict adherence through implementation. Kinda the nostr ethos.

Just m' thoughts. You guys have a great day.

[louhutchinson]

@vitorpamplona tried to merge ideas. failed. I'm looking to implement a client side solution to mitigate influenced prioritization from outside. Can't keep it any simpler.

[staab]

The first paragraph is contradictory within itself. Assuming you've accurately captured the "nostr ethos" of thick-client/thin-server.

Sort of. I can see how it can be confusing. Clients can only be so thick without introducing a server. This NIP basically requires clients to run a caching service like Primal's in order to implement it, which is a centralizing factor. Counter-intuitively, sparing use of thick servers with standard interfaces (relays or DVMs with algorithms baked in) make it possible to avoid heavy use of thick servers with proprietary interfaces (clients with a hard dependency on a third party service).

Your idea as you have explained it in this paragraph depends on relay-pinning. If that isn't antithetical to the nostr ethos, I'm newer here than I thought.

Explicitly selecting a relay is ok if you trust the relay. This is something users do all the time with regular relays. The goal is to reduce the level of trust required by adding redundancy. If you're concerned about algorithm providers censoring data, use more than one from different parties. It's the same problem.

My main point here is that clients simply won't support this NIP because of its complexity, which makes it non-interoperable by default. I think it's also worth mentioning that if you want something as flexible and omniscient as this NIP would require implementations to be, you might want to just use @jb55's nostrscript, which is turing-complete and can do everything.

Also, responding to your earlier comment:

I find unions, intersetions, and diffs to be more sophisticated than what I've proposed.

Yes, more sophisticated, but less powerful. The set operations allow end users to compose simple building blocks. Staying to a reasonable subset of the spec allows clients to compile feeds to standard filters, which helps with implementation complexity, and allows for using regular relays as a backend.

Since I dont see an actual PR for that idea, I can reach out to the poster of that wiki and see what thoughts he has for inclusion or whether he would like to make a separate proposal.

[jb55]

you might want to just use @jb55's nostrscript, which is turing-complete and can do everything.

soon ™️

[vitorpamplona]

I'm looking to implement a client-side solution to mitigate influenced prioritization from outside. Can't keep it any simpler.

Looking forward to your client. Let's see the power of this.

[louhutchinson]

Its worth quoting nostr.com here since I have seen psuedo-philosophical responses here about what nostr is/isnt/supposed-to-be/resisted.

"Resilient

Because Nostr doesn't rely on a small number of trusted servers for moving or storing data, it's very resilient. The protocol assumes that relays will disappear and allows users to connect and publish to an arbitrary number of relays that they can change over time."

And then the suggestion of using an AI bot to sort/filter user feeds... lol. You guys are hilarious.

Here's a refreshing take:
https://fiatjaf.com/nostr.html

Quite literally everything opposed to the stabs taken at this PR. Pun intended. Go ahead and never this. Your positions are documented.

[louhutchinson]

LMFAO, clients are unable to read/execute sort parameters from a json object. Retire now. Run fast.