Nostr Web Client

I’d love to replace URLs, yet I think they’re here to stay for some time. They also appear to be reasonably censorship resistant - while I think ICANN and their shit-domains strategy is borked - you have countries and domain TLDs not solely under a single/coalition countrie’s laws/control. It’s still centralised - and no silver bullet.

Long live:

The Pirate Bay

Wikileaks

Etc

URLs are particularly useful around services that need some centralisation - like a paywall or paid service. How can you trust a decentralised someone to collect money on your behalf and validate payment for access your service or content?

brugeman 2y ago

Can you please elaborate on why something needs a URL (domain name) if a paywall is needed?

The simplest nostr-native way to have a content paywall is 'zap this note, get DM with content'. No URLs.

The simplest nostr-native way to have a paid service - 'zap this note, get 1 month of our service for the zapping pubkey'. No URLs.

I think we habitually assume that nostr needs to integrate to the web, that web is more fundamental. That is kind of true for now.

But I've come to think that if we succeed, things will flip, and web will become just one of presentation layers for nostr. And nostr pubkeys will be much more important than domain names.

Reply to this note

Please Login to reply.

Discussion

Blake 2y ago

For dead simple one off pay and receive, delivery via a Nostr DM - for sure, no URL. Only a common relay URL/domain is needed. But if your event has an image or video (and you’d prefer not just to be a secret sharing approach, like a ‘anyone with this private link can read this file’ approach), then how do you control who can access the image or video in this scenario - without the risk of someone sharing the access publicly? Obviously downloading and reposting is possible too - however it’s impractical at large scale (like where is the YouTube clone that rips all their content?). Largely tied to demand (like ripping movies/series).

For example two, how does the user access the service? A relay URL? A URL/domain to configure for translation APIs? Depends how your service is delivered. If you use a Nostr event request and response approach, using like a HTTP Nostr API to access it, sure that can work - I’m less convinced it’s suitable for many use cases, as Nostr events have real overhead many performant/scalable APIs don’t need. Maybe in 5-10 years the overhead will be negligible.

For situations that require repeated/future access (did pay, is current member, access not expired, etc), where there is an access check mechanism, it needs some centralisation (if again you care about its distribution). Maybe some key exchange encryption can work - however it doesn’t have the same properties as being having a centralised gateway.

I may be overlooking something, and I’m hoping other methods exist - I just don’t know of any that have the same or better attributes than a URL/Domain approach today.

Domains/URLs are really just pointers, I entirely agree. Controlled distribution is just one use case they support well.

brugeman 2y ago

These are all valid questions. My point is that nostr events can be entry points to access the lower level service delivery mechanism. You subscribe on nostr, and you ask for access endpoint on nostr, and then you connect and use it. Next time, the endpoint may change, URL is no longer the address, it's a lower-level implementation detail below nostr event. That's where we're going, I think.

fiatjaf 2y ago

Zap addresses are URLs.

brugeman 2y ago

Good catch, challenge accepted.

Zap addresses are already an implementation detail under nostr events - people zap a profile, they don't care what 'zap address' is.

But we could go further, I could write something like my_npub@provider_npub as my zap address in profile and if clients could talk to provider_npub using ephemeral events then we'd get rid of urls. This would allow one to accept zaps to their LN node behind NAT. IIRC you were proposing something similar during zap nip discussion?

fiatjaf 2y ago

No, my proposal was just to not have clients do 2 HTTP request but just one during the zap process.

fiatjaf 2y ago

But relays are URLs, you can't escape that. I don't know why you think URLs are so bad. It seems like you want a fully p2p network, in that case other means should be preferred over Nostr. I think trying to turn all internet communication into events inevitably leads to a slow, bloated and nonfunctioning experience.

Cameri🐦‍🔥 2y ago

We have kind 2 recommend_server events which could be useful for that.

brugeman 2y ago

I don't like switching btw my nostr app and web. I don't like looking for relays on some clunky websites, and copy paste meaningless relay urls. I don't like when domains I use are blocked by local firewalls. If we abstract them away nostr experience might be smoother. I am fine with urls under the hood.

What do you think about nip97?

fiatjaf 2y ago

At first glance I don't like it because it tries to shove p2p communication into Nostr, like many other proposals floating out there, and I don't see how that can scale. But I haven't inspected it very closely yet.

brugeman 2y ago

Thanks for the feedback.

fiatjaf 2y ago

I don't like clunky websites either, but I think they are necessary if we want Nostr to keep working without becoming the silo of some centralized app that makes everything easy. I could be wrong. The experience of finding relays and other URL-based services could also be much better and not necessarily require clunky websites.

kukks 2y ago

This us this https://github.com/lnurl/luds/pull/203

brugeman 2y ago

Yes kinda this, but I like the fiatjaf's comments under that PR. Besides, since zaps are public, there wouldn't be a need for encryption etc, so zap-over-nostr NIP would probably look simpler.

And I'm totally not an expert on LNURL, just noting that zaps could probably use nostr as transport and not depend on dns and a clearnet address.