I suppose that the alternative to advertising is direct monetisation with bitcoin, and without ads privacy invasion might go away. Can you please talk more about the scaling debate, and how things ended up on the server, which is counter intuitive - moving more to the client should scale better.
Super-sonic problem solving
nostr:nevent1qqspw2erw7gy6hfa0an3w9435razlcc5kl860txsy8kepzhux44yhwgppemhxue69uhkummn9ekx7mp0qgspwut66nfqu2jztndq5gv4vf9q5jnncnmfwhckk9vnljrl53hj6kqrqsqqqqqp5fzx4f
nostrconnect is for app to redirect to signer, bunker is Pablo's invention for signer to app, and npub or token are nsecbunker-specific non standard ideas.
Take a look at this prototype. It's a Nostr signer web-app - it works in your browser, doesn't need extensions, and stores your keys locally.
I love the recent ideas by @PABLOF7z and @rabble about OAuth-like nostr signup/login flows, but OAuth is so smooth because it works on the web - no extensions or apps needed. And the only Nostr web-signing option we had until now was to give custody of your keys to a remote nsecbunker, or paste nsec into every app.
This app, though, is a pure web app, and it does signing locally. It uses NIP46 just like nsecbunker, so it shouldn't be too hard for apps to start supporting it - the one that already works is Snort. With nip05 names added on top we can make signup/login flows that are very smooth and users would only deal with email-like usernames and passwords, without the custody of keys by third-parties.
Ok, let's watch the demo. Your eyes will bleed, but it's a prototype. Maybe #nostrdesign team would help us turn it into something pleasant.
https://video.nostr.build/b3bbcd1aa40ca6d1a3175f6690171e859dc85d41d7f4878b1bbc8f9b9c264fa9.mp4
This approach technically works across devices, but that's unreliable on mobile if device is locked, plus your devices are offline sometimes, so the best way would be to have this app store keys on each of your devices so that at least one instance of the signer is always online (on the device you're using right now). That's why this app has built-in password-protected cloud sync for keys.
It's open source.
App: https://login.nostrapps.org
Client: https://github.com/nostrband/noauth
Server: https://github.com/nostrband/noauthd
I meant not just 'password-protected cloud sync for keys', but 'end-to-end encrypted-by-password cloud sync for keys'. Your password or keys are never exposed to the sync-server.
True. But DVMs are 10x harder to work with, they add latency and UI complexity. I will eventually wrap some of our APIs as DVMs and we'll see if they get any meaningful adoption this way.
Zapper app is for zapping events that have a zap-split set up - meaning first you have to create a zap-split event somehow, and then you can zap it with zapper.
Different apps create zap-split events for different purposes, but I haven't seen an app that allows you to manually build a zap-split - like choose event kind and choose zap receivers etc. I created the above zap-split manually from terminal, if you can do that try reading nip-57 - it's just "zap" tags with receiver pubkeys.
That's what I meant with "full support" - this new user has no relays in kind:3, and you're not reading from kind:10002 - so which relays are used when they post? Only your relay? Some default ones?
Iris is merging with Snort, and I'm not sure which version is served now at iris.to and whether it is maintained. That might be the reason why your messages aren't visible on iris. Or it might be the relays problem.
Try snort.social, login there, go to profile, settings, relays - make sure you have a lot of relays, try adding some bigger ones like relay.damus.io, relay.nostr.band, nos.lol - use nostr.watch to find some.
Then try posting on Primal - they might not have full support of many relays right now because they use their own middleware, so I hope that if you setup relays in Snort then Primal would post there and it would be better visible outside of it.
I mostly use Snort on desktop, other good ones are coracle.social, nostrudel.ninja, satellite.earth
Spring's decryption is in native code, I didn't measure the performance but from your description of the issue I'd say it's probably js-specific problem.
Not really, unfortunately. You'd have to use mobile Chrome and connect it to desktop dev console to debug properly. Spring only shows logs on the About page, and even those aren't convenient at all.
The way it works is that Primal is asking for your pubkey from extension every time you reload. They could cache it as 'last-login-pubkey' in localstorage or something, but they choose to just ask. That triggers the confirmation screen. Most other clients save the login pubkey and that's why won't re-confirm on reload.
Iris is merging with Snort, and I'm not sure which version is served now at iris.to and whether it is maintained. That might be the reason why your messages aren't visible on iris. Or it might be the relays problem.
Try snort.social, login there, go to profile, settings, relays - make sure you have a lot of relays, try adding some bigger ones like relay.damus.io, relay.nostr.band, nos.lol - use nostr.watch to find some.
Then try posting on Primal - they might not have full support of many relays right now because they use their own middleware, so I hope that if you setup relays in Snort then Primal would post there and it would be better visible outside of it.
I mostly use Snort on desktop, other good ones are coracle.social, nostrudel.ninja, satellite.earth
The way it works is that Primal is asking for your pubkey from extension every time you reload. They could cache it as 'last-login-pubkey' in localstorage or something, but they choose to just ask. That triggers the confirmation screen. Most other clients save the login pubkey and that's why won't re-confirm on reload.
@cloud fodder do relay.tools relays support nip42 auth so that only specified authorized clients could post? I mean so that relay would accept events authored by anyone if they come from an authenticated client?
I'm not sure bounties and competition are bad. Right now there is total lack of competition for solving issues, so some incentives to ignite it would be useful IMO.
A simple implementation of nip42 with some fixed set of pre-configured pubkeys doesn't seem too difficult from what I see in the code. The scope of "full support" (relay+sync+stream) mentioned in the github issue plus the desire to make it an extensible plugin might be the thing blocking it.
Well we're looking into a simple "AUTH-for-write-access" policy, so if you have "“AUTH only” middleware and then connect the user directly to the relay backend" and can share it that would be awesome.
100% agree that the bigger the problem scope, the harder it is, but then a big problem scope is itself a problem. I think bounties for github issues are a much better way to do these incentives, as the scope is usually much smaller. And if the issue is of a big scope then you can just create another smaller-scope issue and attach bounty to that one.
I mean that if I want to create a relay for some 'curated' set of events then I would just allow only one pubkey to do writes (write anything, not just it's events), and let everyone else read. Curation could happen manually - I could use some tool to broadcast specific events to that relay, or by some software with keys that are allowed to write.
I think even this seemingly simple 'auth only for writes' case isn't trivial - if you send AUTH to every new connection then you're forcing readers to auth. And if you only send AUTH on writes (EVENT commands) then there needs to be a mechanism to handle the pending write - relay would either have to reject the first write attempt, do AUTH and then client should retry, or relay should buffer the write request, do AUTH and commit the write if auth succeeds. And since clients can't launch the auth flow, writers can't initiate it themselves, they have to wait until relay decided to run the auth flow. NIP-42 isn't great.
Maybe that's not a great solution btw. If a dedicated writer is mistaken and decides to delete some event from strfry - what should it do?...
Maybe a better solution is some relay management interface/port/etc. It could require auth for all clients and support more commands (at least delete). Do you know if there is anything like that planned/built for strfry?
Hmm interesting, yes that's also a possibility. Although it means I can't use existing tools to broadcast mod writes. But then adding nip42 for writers makes most tools unusable too. 🤔
That's fun, but it sounds like such logic should be handled by separate writer/automation process with custom logic.
How about a bearer auth token in headers that allows writes? This would exclude most of existing software to rebroadcast notes to that relay, but it should be trivial to implement at strfry and then we could build various "plugins" that would handle the above or other interesting curation logics.
Oh shit that's true, no websocket headers from browsers :(
It could be a 'secret' included in url but then it will be logged by every damn thing in the middle of you and the relay, not sure if passing long-lived secrets in urls is a good practice.
Also not sure if using secret url is a good idea nostr:nevent1qqsrcndt8wmv7erlccjf6kcamsr2pzferkxa70fcc0fk3q2gny7wnmqpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59upzqv6kmesm89j8jvww3vs5pv46hqm7pqgvpm63twlf9hszfqzqhz7aqvzqqqqqqymcd79w
Oddbean new post about login | logout
Notes by brugeman | export
There is a relay for that, wss://feeds.nostr.band/lang/{lang} - en, es, jp etc., i.e https://nostrrr.com/relay/nrelay1qq08wumn8ghj7en9v4j8xtnwdaehgu3wvfskuep0d3skuee0v4esg0z4rx