blakejakopovic

FROM alpine:3.6
RUN apk add --no-cache rust cargo
COPY project /build
WORKDIR /build
RUN ["cargo", "build", "--release"]
ENTRYPOINT ["cargo", "run", "--release"]

blakejakopovic

NIP-YY

Nostr Service Definition

draft optional author:wakoinc

A standardised service definition event allowing services to broadcast services they provide, and client apps to impliment support for a service type that is inter-changable

blakejakopovic

NIP-ZZ

401/402 Unauthorised/Payment Required Nostr HTTP AUTH Flow

draft optional author:wakoinc

This NIP is an extension to NIP-98 which allows HTTP authorization using a base64 encoded event header. This NIP documents a typical protocol flow for failure, retry and success - or hard fail.

blakejakopovic

require 'sinatra'

get '/public/AUTHIMAGE.jpg' do
  auth_header = request.env['HTTP_AUTHORIZATION']
  puts auth_header

  # Check if the header value starts with "Nostr "
  unless auth_header && auth_header.start_with?("Nostr ")
    headers['WWW-AUTHENTICATE'] = 'NOSTR-NIP-98'
    headers['Access-Control-Expose-Headers'] = 'WWW-Authenticate'

blakejakopovic

Nostr 'My Services' Event Kind (Draft/Experiment)

A way to support in-app management of services with subscriptions and credits where a payment is due (I guess it can be free too?).

Client UX

A client app can query for these events and show a list of services that are active or have credit remaining. They can show a list of expired (or no credit left) services as well. Clicking a service can allow you to make a payment based on the payment options provided.

What to support

• Current balance (optional if expiry exists, else mandatory)
• Current expiry (optional for balance): Represents payment due by

blakejakopovic

Pain Points / design limitations

• Limit is useless for subscriptions with multiple filters (as how to prioritise which filter results are most important? Left to right?)
• Hard to do pagination (using since/until, but what limit to use? What if older events shared after you fetch, you’ve now missed it)
• Race condition between EOSE and CLOSE subscription when you don’t want to stream (option to only return existing data only, without newer broadcast results)
• Events from new pubkeys are missing basic kind0 data (ideally embed name/display_name for first pubkey event)
• Websocket congestion control and bottlenecks (single event streamed at a time, blocked by larger events FIFO)
• Unable to query for ranges of kinds (e.g. {"kinds": [30000-39999]})
• More?

Missing Features

blakejakopovic

Nostr Client App Anti-Patterns

With Nostr being an open protocol, and client apps being able to be developed by anyone, it's important that the client apps design around best supporting relays by minimising their client app impact. Remember, if your app has 10,000+ users, and the app's relay interaction code makes relays slower - everyone suffers.

Below are some anti-patterns (things not to do), that can help with relay performance, and ultimately make your client apps faster!

Please help build upon this list - we can move to a repo.. just add comments for now.

• Updating a subscription too often (triggers new SQL queries)
• Connecting to a relay multiple times (use a single websocket)

blakejakopovic

#[macro_use]
extern crate log;
use anyhow::Result;

use bech32::FromBase32;
use secp256k1::hashes::hex::ToHex;
use std::convert::TryFrom;

fn parse_tlv(data: &[u8]) -> Vec<(u8, &[u8])> {
    let mut result = vec![];

blakejakopovic

require 'sinatra'
require 'json'

# class App < Sinatra::Application

  configure do
    enable :sessions
  end

  get '/' do

blakejakopovic

NIP-XX

Proof of Work Service Provider

draft optional author:wakoinc

This NIP defines a way for clients to request a target proof of work calculation for an event prior to publishing.