https://github.com/shocknet/smart

Slightly More Advanced Relay Technology for NOSTR
https://github.com/shocknet/smart

Last synced: 5 months ago
JSON representation

Slightly More Advanced Relay Technology for NOSTR

• Host: GitHub
• URL: https://github.com/shocknet/smart
• Owner: shocknet
• Created: 2022-11-27T17:34:23.000Z (over 3 years ago)
• Default Branch: main
• Last Pushed: 2023-10-14T16:41:48.000Z (almost 3 years ago)
• Last Synced: 2025-01-14T03:32:12.232Z (over 1 year ago)
• Size: 4.88 KB
• Stars: 3
• Watchers: 1
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • Funding: .github/FUNDING.yml

Awesome Lists containing this project

README

          
# SMART

*(Slightly More Advanced Relay Technology (for Nostr))*

`rfc`

**PURPOSE**

A middleware service that provides a performant interface to nostr, by sitting between client applications and relay-networks, to run logic that is beyond the scope or NIP compliance of core relay implementations. These added capabilities or “SMART Routes” are enabled by server-side caching, indexing, and rendering that would otherwise have to otherwise be done client-side and cause poor usability.

SMART Routes should supply only results that are contrived from NIPs, and are therefore verifiable. A client appending `/proof` to their request should expect the raw events needed to reconstruct a result. Routes are to be defined similarly to NIPs, but with the assumptions of being an application back-end rather than a client-side protocol.

Unlike NIPs, an SR is referenced by name instead of arbitrary numbers. For example, a route for GET `/smart/npub/nip05/` would be referenced as `npub-nip05`.

SMART is **not** intended as its own relay, but drop-in middleware for client applications, that will in many instances forward raw events and requests.

**Example usecases:**

- A nostr-based contact list in lightning wallet:

    - User inputs their `npub`,

    - Client GETs `/smart/npub/contacts/`,

    - A list of all accounts the provided npub follows is returned.

    - Each contact returned would contain lnurl or lpub `payee` information from its indexed metadata, and could thus be used by the wallet for the sending payments, as well as other profile display information like avatars, pet names, etc.

- Key Delegation:

    - Responses should include data published via delegated keys to save a client multiple round trip look-ups. Indexes enabling this route could combine multiple delegation NIPs into a single GET response.

**OTHER NON-ROUTE FEATURES**

- Scavenging and Forwarding Policies

    - Write events received from clients may be forwarded to other networks.

    - Other networks may also be queried if local results are unsatisfactory.

    - Service publishes forwarding and scavenging policies

        - Clients may use these to help a user determine if they want to specify additional networks for use.

- Scalability

    - Uses relays as write-leader for eventual consistency.

    - Access tiering

    - Highly Available

- Private API

    - Chaumian tokens, sold to or earned reputationally by clients, allow ephemeral keys to write without leaking who whitelisted them.

    - Authenticated routes can protect metadata Direct Messages and other sensitive kinds.

**DEFINITIONS**

- Unsatisfactory Results

    - No results for specified kind / tag / age

    - Signatory has tagged a relay that is not in scavenging array

**ROUTES**

- Stable

- Dev

- To Do

  - npub-avatar

  - npub-name

  - npub-nip05

  - npub-payee

  - npub-contacts

  - npub-delegates

  - npub-relays

  - raw-write

  - raw-req

  - nevent-

  - nevent-

  - nprofile-