Skip to content

algorithms on nostr that have a chance of working #522

@huumn

Description

@huumn

Nostr already has an "algo" all relays use to order events. The algo is "sort by created_at in descending order." What I want is a way to ask relays for events using a variety algos such that algorithms are

  1. provided in a censorship resistant way
  2. transparent
  3. compete

I'd like to get some initial feedback before drafting a NIP.

I'm unsure of the nostr idioms but we need a way for clients to specify an algorithm and its arguments.

What I'm thinking:

{
    kinds: [1],
    algo: [ALGO_NAME, ALGO_ARG1_NAME, ALGO_ARG1_VALUE, ..., ALGO_ARGN_NAME, ALGO_ARGN_VALUE]
}

Where ALGO_NAME is an algorithm, and the rest of the array are argument name-value pairs spread into an array of strings. Algorithms should be rigourously specified as their own NIPs and clients may check for ALGO_NAME support and request events using them. All normal REQ arguments should be respected like normal and operate on the algo's input or output set (where the REQ args are applied, if relevant, should be specified in the algo's NIP probably).

e.g.

{
    kinds: [1]
    algo: ["TrustRank", "degree", "3"]
}

Anyway, that's the gist of what I'd like to propose. There's more to consider like how clients reconcile different results from relays, etc, but I'd like to guage if there's interest in this approach to algorithms first.

Is this the right idiom? Is there prior work I should be using instead/considering?

Alternatively, a new verb, much like COUNT could be proposed. wyt

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions