I agree, it's the same thing prone to similar issues/errors (copying the nsec and then accidentally pasting it somewhere, etc). We support import of encrypted nsec (nip49), but most apps don't export in that format. If you have any ideas here I'd be happy if you shared them.
One thing I will add to the mix: I think nip46 (Nostr Connect) is missing a standardized "import nsec" flow, i.e. app could generate a key for new user (to reduce onboarding friction) but then if/when user wants to reuse the key in other apps they could choose a provider and app should somehow pass the nsec to the provider, i.e. redirect to provider.com/import/#nsec or something like this. This would mean there is no copy/pasting, and we wouldn't be "training" the user to mess with their keys.
OTOH maybe this whole "let's hide keys from the user" thing is a mistake and we should instead educate them better etc. But my own experience looking at how non-tech users are trying nostr tells me that people won't read, they will only click big red buttons on the screen and hope for the best. Anything above that causes frustration and anxiety. What's your view here?
If we do try to educate users then at least we should do this gradually. Forcing someone to learn keys/relays/etc when all they wanted was to post a "like" or write "hello world" makes no sense. There should be a super-easy way to start and get the value user expected, but then a gradual process of explaining why things are the way they are in the context of tasks that users are trying to accomplish. That's probably 100x harder than just snapping a couple explainer screens here and there.
I am thinking of adding this to nostr-login, it will need server-side support by the app ofc.
Questions:
- do you think there is any particularly good approach we could take that would help us make otp server api a nip?
- what if instead of server issuing a session token client would generate a session key and sign otp with it, the server could use this npub as session id, client could use standardized stuff like nip98 to sign requests, etc. Is this a good idea?
I love this, and read-only mode by default to try the app.
One issue with this is verifiers are shown by the app itself - so it could be faked by the app, and the More info can lead to a fake page that user won't discern from a valid zap.store page. Looking at verifiers makes sense only in a third-party independent app that you already trust (zap.store).
That's ok, especially given the fact that onboarding a new user poses no risk for the newly created key - there's nothing valuable tied to it yet. My concern is when this flow is used to login to apps with existing valuable keys - you don't want to trust the app itself to show it's own verifiers.
Onboarding is the same as with other nip46 providers (except for request for push notifs), Safari will improve when Push API is out of experimental status there. Use of existing nip05 is possible, it's on the roadmap.
Fake zaps have in principle no difference from fake reviews. It's a bit harder to fake, but at scale there will be services automating it, just like there are services for fake reviews. Wot solves for both zaps and reviews, we solve wot - we get useful signal from any kind of interaction.
I agree this is early to tell if a number is useless. But it can definitely be misleading. A distribution of those scores will most probably be power law - top guy having multiples higher score. To an average person it would seem as if top guy is 3x "better", while that's definitely not the case. How and when the numbers are presented is probably a very important question.
Test reply. Also, those proposing DM subscriptions (at least some of them) probably think about paid restricted content. Not just "how to make sure it gets delivered".
Ok so I need a storage server integration for our product. Blossom is very simple spec focused on fighting link rot and decentralization, key to which is that uploaded files must not be modified, so my app wouldn't have to trust the server. Blossom invents it's own auth instead of nip98, needlessly.
Wrt nip96, which I didn't consider, but looking at right now, it's much more verbose and covers a lot, and uses hash for addressing, but lacks one critical thing - I want to ask the server to keep the original and do no transformations. Adding this one option would make it a superset of blossom and I would be able to use it. Maybe there's such an option and I missed it in the nip96 spec?
You are right 99.99% of the time it's ok to trust the media hosting someone is using for trivial memes etc. But if some controversial video is released, it would be great if anyone could re-upload the original to other servers and they'd all serve the original and any client could verify it's original, etc. That's the problem blossom is solving.
Re. my use case, I'd like to host some code in the same "link rot avoiding way", and I know you wouldn't probably transform it anyway, but I will also upload images that shouldn't also be transformed. I haven't considered git, and maybe I could even just host it all in nostr events... We'll see.
My point in posting here was to understand what problem blossom solves vs nip96, and I'd say a small addition to nip96 could make it supercede blossom and you could then just ignore it :)
I agree with you about imgproxy, but then there's no NIP for "accepting optimized version after the fact" and I'd say it's probably much trickier than you say. Anyways, you don't have to offer this option if you don't like it, I'm just comparing the NIPs.
100% agree, that's why I'm saying offering this as nip96 option (even if paid, restricted etc) could serve those use cases, and I'm guilty as anyone in digging hyped stuff without looking through existing NIPs first. And you sure didn't waste time implementing nip96, it seems to be quite good, even if a bit too verbose for my taste.
On your takeaways:
> - over half the Nostr listed relays are using some sort of spam mitigation technique(s)
That's great to know!
> - the attack was still achieveable
Attack of what exactly? You wasted 10gb of space on some relays, and got to top on one app. Other apps were fine.
> - socal media is easily manipulated
Nostr? That specific app?
> follower counts and engagement are worthless
They work in some context and not in others. For algos, i.e. that order profiles by popularity, fc is bad, which was always known, and no "spam prevention" will change that.
> - content is the real treasure
How can this insight help improve the app that you attacked? How can it help prevent spam?
Actually there is a "browser relay", Snort has it, Spring browser too. Not sure about Snort, with Spring it's a fake Websocket interface installed to global that will redirect all requests to a custom "local-relay" url to a relay running in a service worker. There's a dumb relay in sw now, which I didn't bother to make efficient yet, but it can be improved. The main limitation is browser js performance and storage size limits, I guess.
But this is only for your own app. If you wanted to share this relay, that's possible too using postMessage for cross-origin communication (with the same fake websocket installed in the app to trick the libs it's using (ndk/nostr-tools) to use the local relay). Haven't tried it though, there a limitation will probably be that the relay tab must be kept open.
Actually, an app could open an invisible iframe and talk to it using postMessage, then no need for an open tab, the relay would live in the iframe's service worker. Could be pretty cool!
Websocket proxy talks to the relay running in a worker using comlink lib which is part of the framework we used, but that's just a wrapper for postMessage
I believe wot is the solution, and global state/metrics/algos have limited future. We don't use 'number of links' to measure the popularity of a website. We don't really even have a concept of such a metric on the web (that normal people would understand), that should tell us something.
That said, the only hard-to-game metric that worked reliably at huge scale is pagerank. But it's costly to calc, and thus only a few would run it, and results depend on the inputs which will differ, and so competing ranks would always differ, even if they were based on the same algo. And then it's just a meaningless number to most people, only usable for algos.
Also there's a difference btw knowing how many people follow you (you know whether you cheated or not), and how many people follow others (when you want to compare yourself just for fun), and a reliable metric usable for algos.
In short: follower count of yours is a fine metric most of the time (to estimate how many people might hear you), follower count of others to compare to yours can be manipulated but that's unlikely and harmless, follower count for algos is a very very bad idea - pagerank for global, wot for personalized.
Filter by tag is best first start!
I'm not about a "kind for posts", I'm about "kind for describing a website". Right now you specify an author npub, but if you start using custom feeds etc it might get more and more complex, so maybe "blog" could be it's own event and then options and settings could be written there and it could be discoverable, gain WoT etc.
I published a new nostr-login version, there's now a data-methods option, a list of comma separated allowed auth methods, you can specify 'connect,extension' to exclude 'readOnly'.
I was trying to use the sdk on nodejs yesterday, first I had to add some fake FileReader with readAsArrayBuffer, then it started failing on stream().pipe, so I had to make my custom uploadFile. I have no idea how to deal with these cross platform issues properly, if you do, would be awesome to have it working on nodejs well. Thanks!
@Stuart Bowman two questions on Satellite CDN:
- I paid for 1 Gb, still getting Payment required when trying to upload using blossom api, anything I'm doing wrong?
- maybe you could put nostr-login to the payment form, it would allow me to use Nostr Connect while paying?
Thanks
Ok so the 'nitter' thing that I was relying on for scraping Twitter is so dead that even my own instance of it no longer works. I guess it will stay this way for a while/ever. Considering that almost nobody even tried xtonostr I won't be trying to fix it anytime soon. Sorry.
Oddbean new post about login | logout
Notes by brugeman | export