nostr:nprofile1qyvhwumn8ghj76r0v3kxymmy9ehx7um5wgcjucm0d5hszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgsq29me0  what do you think of the idea of relays having normal web2 HTML webpages that people open in order to register or set up something?

I was thinking of your "invite" scheme and how it could be done with just browsers and webpages without all clients having to write native integrations for it.


I’m not Ned Flanders but I think it’s a great idea.

My sons school wanted me to use WhatsApp (closed group) to get official info. If they had their own relay, parents could then use the client of their liking to get the info.

But the relay has to be easy to setup and configure for the school, and easy to access for the parents.


This is another great use case.

Although with NIP-29 they could just rent space in some relay provider.


True, a simple group chat is enough. But imagine, you buy a box, you plug it in, configure it via browser and you can admin multiple groups via your own private relay. Sovereign.

I worked for a network of schools. Coordinated multiple classes within the same location, all within an international network. If each school had its own relay, with some data being automatically propagated through the network (global or area), while other only remaining available to local (school relay) or group (class) most of the headaches I encountered would have managed themselves. If one school fucks it up by mismanaging their relay, they can recover from the network. We had students moving from one location to another and whole sorts of data portability problems.

Fuck, I should go back to pitch it to them even though they’re cunts. They attract interesting students, and do teach programming as well.


Similar to Nostream's paid registration?


Yes, the Nostream registration page is the way to do it, I think.

Better than trying to shove everything into all clients.


Who is Ned Flanders?


ned flanders https://media1.giphy.com/media/guQCh1RPgIOpG/giphy.gif?cid=6c09b952e4s9py2kjy2ro37bb73lldewx6apjqktufarybk7&ep=v1_internal_gif_by_id&rid=giphy.gif&ct=g


A character from the tv show The Simpsons


I tease nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn that he is nostr’s Ned Flanders

It’s because of the pfp with the moustache and the religious fervor


… and because he’s ripped


Did you really have to say The Simpsons is a TV show?

What is a TV show?


What is a TV?


I vote yes, but in my case the more tightly integrated interface makes sense because the client and relay are tightly coupled


i vote no because tight coupling creates hard to extend architectures


Stupid sexy Flanders


The best show


Hey be nice his wife died to a t shirt gun


I'm not talking about technical coupling, but about coupling within the domain. The same people are running the relay as the client


it's an interesting idea but exceedingly simple to implement, literally just add new thread to the startup code that launches a web server

it has some nice privacy preserving effects so there's that too, but it is a shared resource, so it has other kinds of security issues to concern yourself with (users on the same server finding ways to get at other users data)


How does that work? Is it a proprietary thing?


It's this thing: https://github.com/nostr-protocol/nips/pull/1079

The instances are white-labeled coracle/triflector deployments that are hardcoded to talk to each other. I'm going to make a video about this soon.


the client surely has to derive a private key from the invite though if i understand the proposal, and this private key needs to be stored by the user for security against loss

i think a signed code would be more secure, so it would be verifiably linked to a privileged user on the relay (like giving the relay an identity, this is something i'm working on right now), what's to stop a permutation attack if the string is short enough?


they need to be hard to generate valid ones though, i don't think you've thought it through


As far as I understand it, Coracle has Invite Links, which includes the claims to authorize access to Triflector relays / groups in the link. If the link parsing oce and the "joinRelay", "publishGroupEntryRequest", etc. functions in Coracle that publish the Nostr events with claims were abstracted into an SDK, that would enable any web2 HTML webpages to grant authorization based on claims without the developer needing to write a native integration from scratch.

I've been thinking about how I can integrate https://github.com/neilck/nostr-badges with this invite scheme, to automate the registration / enrollment part of the user flow.