It's a very good point. Those billions of reviews globally, if you exclude fakes and then divide by the numbers of products out there you get maybe 100 reviews per popular product (median number of reviews for all products is definitely zero). How many of those 100 reviews would be in my wot circle? If the 100 people I follow posted 100 reviews each, I would only be considering maybe 0.01% of all popular products. That doesn't seem good.
The solution could be a wider wot circle, and start from niche, and more reviews. If I knew my reviews wouldn't be lost in some corporate database, I might have posted more of them.
Also it will probably vary based on physical proximity to my contract list members. They would probably review a lot of local products, but not much in Dubai or on Alibaba. So maybe travel is not the best place to start.
Also wrt 'headphones' example. Instead of looking through my wot circle for reviews, I could post 'please help me choose headphones' message that could propagate through my wot circle until some experts see it. They could reply with 'here is a one liner big advice, and here are a couple links for you to read, and if you want to hop on a call - schedule here and it will be 5000 sats'. This might turn out as a better solution to 'help me buy headphones' problem than trying to fix fake reviews or increase the review density in my wot.
Team hackernews, go!
nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqs8drglu0yen4458837le3egjeg6lmwfn2hqulklkve89ejkzw99eqmara3k
Team hackernews, go!
nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqs8drglu0yen4458837le3egjeg6lmwfn2hqulklkve89ejkzw99eqmara3k
So overall, I don't have a great answer from real world practice, as the only products I know that integrated with Nostr that didn't have 'nostr functionality' are bolt.fun (defunct), geyser.fund and stacker.news (both have nostr functionality now). Also maybe wavlake and fountain? Any other I'm missing? Also Mutiny!
However, where I would consider nostr (if it's not a full-blown nostr app) is:
- if I need social graph for my app to function (access 100 connections per user - Mutiny case)
- if I need data for personalization and AI training (train on 1000 liked posts per user) (also personalized stream of zaps in Mutiny)
- if I need virality by social sharing (reach 10000 nostriches)
Does this sound like something saleable?
On the technical side, Nostr auth could work side by side (stacker.news - link to your Nostr account), or it can replace it (don't have an example aside from nostr apps). If nostr is your main identity system it may or may not affect your traditional model - you could just auth all HTTP API calls to traditional backend, or you could do a full-blown nostr app that uses nostr events and relays and no backend. I tried to briefly cover all this on nostrlogin.org but maybe it wasn't all that clear.
Well on Nostr a lot of user data is public. I'm also not sure web3 auth adoption wasn't happening (was it not?) due to the lack of business model for apps. Maybe web3 is too focused on blockchains/shitcoins. We'll see where it goes with nostr.
Btw how does your preferred web3 auth provider solve the key storage, backup, recovery, etc? Removing passwords and 2fa is easy, but is there something to ultimately replace them with?
It's the job of a provider (browser extension or nsec storage like nsec.app) to help users recover. It's not black and white, we don't have to leave users on their own with how-do-I-store-this-nsec thing.
That's right, it's like explaining them how to store and backup bitcoin keys. It's always a facepalm.
That's why there are setups like Casa or Bitkey that don't expose keys, and instead build good storage and recovery tooling. It's not for experts, but most people aren't experts.
Nsec.app doesn't expose nsec too (at least if you don't ask atm), we will try to keep it safe and help you recover without making you write it on a piece of paper.
Well ideally you would only send search queries to it, then you probably wouldn't hit the rate limits, is that possible? It's quite heavily loaded, being one of few relays with full index of events and with search over all of them.
Nostr-login is just a library that you can drop into your app to support many nostr login options - it supports nip07 (extension), nip46 (remote signing/nsecbunker) - using nip05 address and bunker url, read-only login with nip05 or npub. Also account switching is in the works.
Well I guess mostly that's bcs there are no mobile apps with access to camera that could scan the QR, nsec.app could do that theoretically, but I haven't seen any demand yet
The is a video-guide on how to login to Coracle on nsec.app homepage, you should enter your bunker URL or your name@nsec.app
Don't share bunker URLs publicly - you have to put them where they belong, i.e. into Coracle :) Although I agree this bunker thing is confusing.
Nsec.app stores your keys in your browser - there is no 'admin key', all keys are separate. The password you specify is used for e2ee sync of your key between devices - so you can login to nsec.app with name and password and get your keys synched there.
Ok so the 'nsecbunker' is one of the first nip46 implementations, and it had it's own 'connection string' format - it was 'npub' or 'npub#token'. But now the new standardized format is bunker://pubkey?relay[&secret] - all modern clients will support this format, some old clients support the old nsecbunker format. Nsec.app can't work with npub or npub#token format bcs this string doesn't allow to pass the relay address, which is needed to run the nip46 protocol (original nsecbunker had hardcoded relays so that wasn't needed).
Thanks, I will adjust the wording. Basically, there are 2 kinds of bunker urls - with a &secret or without one, one with a secret must not be shared publicly, only pasted to the connecting app, nsec.app generates only urls with a secret now.
Jerks' daily job is to find targets, not sure if deindexing from aggregators would help much, you should then deindex from major public relays too, and only post your stuff on paid relays (paid to read, not only to write). Meaning, you shouldn't be on public Nostr if you're afraid to be found by someone determined to find you.
I think the only anti-harassment solution that could work on Nostr is client-side filtering, based on contact/mute lists, friends' reports, etc. Don't show replies from people you don't follow, or that were reported/muted many times by people you follow, or replies from public relays. I bet some of these policies are implemented an nos.social, but the issue is - everyone's using Damus/Amethyst/Primal, and those have nothing like that.
The way I see it, we should have a separate pluggable layer/API/NIP for content post-filtering, that can be plugged into any app: an app forms a feed (main/replies/notifs/anything) and then passes all the events from the feed to the filter, and filter returns various labels (spam/harassment/nsfw/impersonation/...), and app covers the content of the labeled event and shows labels above it. This way apps don't have to rebuild their feed building logic - just apply another layer above it, users would specify the filtering API endpoint in the settings and get the filtering they want. Safe mode could be 'cover notes from users I don't follow until filter returns it's labels - uncover if no bad labels returned', more reckless mode could be 'show notes first, only hide them if filter returns some bad labels'.
If nos or anyone is interested in experimenting with me in this area, let me know.
Thank you all! Spring is on hold in dev terms, but we haven't published any updates that could break it, so something on your system changed. From the issue you filed I see it's related to webview update - I will keep it open and try to google this stuff to figure out if there's a known fix. Thank you.
Which clients interest you the most?
Most web clients either already support it, or are trivial to implement with nostr-login or window.nostr.js
Native clients are mostly disinterested and I haven't seen any enthusiasm from them, unfortunately.
Let's just go to their github issues and post there?
Coracle looking for relays forever might be the case with brand-new keys.
Nostrudel has everything working in their 'next' version at 'next.nostrudel.ninja', on main branch of theirs you must use bunker URL for now - click 'Connect App' in nsec.app, copy bunker URL, then select Advanced -> Nostr Connect / Bunker option in Nostrudel.
There is also Snort, worked fine last time I checked, just choose 'Already have an account' and paste your name@nsec.app
Oddbean new post about login | logout
Notes by brugeman | export