@greenart7c3 trying Amber finally, can establish a connection using nostrconnect:, but then it won't process any requests. Does it require push api to receive requests? I installed nfty, but Amber says "Failed to register with push", although I see your registration in nfty. What am I doing wrong? Thanks!
Awesome, not it works! But it only creates a connection if I launch Amber on nostrconnect: string, if I scan or paste it it just jumps to homepage, no connection, nothing in logs. The string is the same in both cases, like this:
nostrconnect://cf22596e3e6909d318a1da9b064da70b20b3ab36f2862d38e48c665cbd4e05fe?metadata=%7B%22name%22%3A%22nostr.band%22%2C%22url%22%3A%22https%3A%2F%2Fnostr.band%2F%3Fq%3Damber%2Bpush%2Bserver%22%2C%22icon%22%3A%22https%3A%2F%2Fnostr.band%2Ffavicon.ico%22%2C%22perms%22%3A%22sign_event%3A1985%2Csign_event%3A3%2Csign_event%3A30000%22%7D
nostr:nprofile1qqsw3mfhnrr0l6ll5zzsrtpeufckv2lazc8k3ru5c3wkjtv8vlwngkspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshsptal62 is working on something. But you could start with pasting media urls in kind1 and getting rss with npub.pro
There is a tool for one-time import from Ghost https://npub.pro/import-ghost
But there isn't one to continuously monitor Ghost using it's API and to republish everything from Ghost to Nostr, if that's what you need.
Yes just start from homepage of https://npub.pro clicks Try now, choose theme, login using DM (code sent to your direct messages), then you'll preview your content as a website. You could choose all notes or only long-form, and filter by hashtags.
This is the most difficult part.
A brand new npub doesn't have a wot network from his pov, but that's not a big deal - onboarding client should ask them about their content preferences/hashtags and even if user doesn't choose to follow someone and get his wot seeded, client could use some popular accounts from the topics user has chosen to serve as temporary wot sources.
The bigger problem is that relays can't distinguish a brand new npub from spam. I.e. if someone big tweets about nostr and a wave of new people comes in short time, it's indistinguishable from a spam attack from a botnet. And pow doesn't help much - you'd need something like 100 seconds of mobile cpu to produce pow equivalent to 1 sat - and I bet reply-scammers earn way more than 1 sat per event they post.
I keep getting back to this issue in my head from time to time, and still can't find a good general solution, only whack-a-mole. Users can be protected from spam by wot, but public relays designed to onboard new users can't. Unless we attach some extra signal to new users (pow? 1 sat? some version of your pow endorsement?) while keeping the friction low.
Any ideas how "pow endorsement" could be practically applied to onboarding users at scale with low friction?
> Maybe the answer is that they need a invite of some sort to surpass the "reputation threshold".
That's the only plausible idea to me too, but it doesn't solve someone hearing "nostr" on twitter and googling it and trying to get onboarded.
Captchas don't really solve anything either, they just make spam a bit more costly, but people will resort to them without anything better on the table.
Yes, and what I mean is that the cost of solving a captcha by automation services is 0.5-30$, I pay for it, spam the shit out of that npub for 1 month, scam people on >30$ and get profit. So it might raise the bar, but not really solve it.
NWC wallets don't have static IPs and are behind firewalls too. Clients send ephemeral events as requests to wallet pubkey on some relay, wallet subscribes to requests and replies in a similar way tagging the client pubkey.
Same way wallet could talk to a mint doing RPC using ephemeral events.
NWS is doing similar thing but with a much more complex setup - enter/exit nodes socks5 etc, and the payload is arbitrary binary data, wheres mint RPC would be much simpler and more structured - wallet just connects to a relay and writes/reads some encrypted events.
Some themes have a light/dark switch. We could also try turning the theme into dark using code injection customization. Let me know if you need any help!
Nothing new here.
nostr:nevent1qvzqqqqqqypzqv6kmesm89j8jvww3vs5pv46hqm7pqgvpm63twlf9hszfqzqhz7aqyg8wumn8ghj7cfwdehhxtnvdakz7qgwwaehxw309ahx7uewd3hkctcqyr28854frgvavcu2dd3zhcv2rt2rjqtushl3n29hg8jqllytuf6x6v09m7s
The fact that we're observing some volatility doesn't mean it's different in principle. I don't see any difference in incentives. Only difference is initial audience - web was being grown by tech people, and the only way to participate was to host a web server. Nostr is growing with not tech but freedom-loving people for the most parrt, who for now have some free relays serving them.
Many tech people do have their own relays here, which aren't good for public use, and they shouldn't be. That's why we have outbox model, so that personal relays could participate. The bigger nostr gets, the more valuable being on nostr becomes, the more relays there will be, run by people with profit motives, for themselves and their following.
Most have given up because they just came to try "running a relay", not "to host my own content for me and my friends". They weren't creators, they were devs. And for creators, tools for relay management and access policies aren't there yet.
Running a public relay is hard - spam, costs, etc - I know what it's like with our big one. Running a personal relay that has strict access policies has no such costs. We run two specialized relays that have zero ongoing costs or scaling issues, just 1% CPU of a server we're paying for anyways.
Search is served by 2-3 specialized relays, some clients don't even have them configured properly, and matching is pretty basic so you have to know exactly what you are looking for, and it's pretty slow, and the search database is usually incomplete. There's no good solution to this yet, it's a hard problem.
The best tech analyst I have seen!
nostr:nevent1qqsyg73u05lx0q6zpu6uy2qlmne69dn98t4vgdqxvjv3rdp5g39rlxcppemhxue69uhkummn9ekx7mp0qgs03ekxgdp0rczjfqrrpcn7zqtdec6lcwnpfesyxnl0f239qvege2grqsqqqqqpdss8pp
The best tech analyst I have seen!
nostr:nevent1qqsyg73u05lx0q6zpu6uy2qlmne69dn98t4vgdqxvjv3rdp5g39rlxcppemhxue69uhkummn9ekx7mp0qgs03ekxgdp0rczjfqrrpcn7zqtdec6lcwnpfesyxnl0f239qvege2grqsqqqqqpdss8pp
Maybe instead of fighting relays that try to limit abuse with limited tools that they have, we should discuss the issue?
What's your ideal relay? Has no limits on number of concurrent connections, subs, requests per second and bytes/events served?
So basically:
- higher limit on number of active subs - then other filter/etag/pubkey limits could be handled by splitting into several subs
- higher limit on number of connections
?
It's not about convincing, but about improving the rate limiting system. The actual load is roughly equivalent whether you send 1 sub with many filters or 10 subs with less filters in 1 conn or 10 conns etc - you need that data, you will request it one way or another. Rate limiting at sub/conn level is just a dumb way to evaluate and limit the load that client is creating. Better rate limiting would take into account the actual number of indexes touched or table scans performed or filter conditions matched for incoming events and events retrieved and served on per-IP basis, then number of filters/subs/conns wouldn't matter.
Could you please publish an example list of subs that you'd like to have persistently active, so that we could have some rough idea of the potential load it could create? Also for pre-sync state and after-sync state - the sync load probably differs greatly from the "watch-for-updates" state?
It's been painful to build the current (pretty dumb) event sync for npub.pro, so I agree things need to be improved in this area.
Also, batching filters might result in unintended expansion of result set - instead of 2 filters {npub1,kind1} and {npub2,kind2} sending one {[npub1,npub2],[kind1,kind2]} may return much more than was needed. So it seems like relays should allow more of precise (smaller?) filters.
You can put _@sachin.npub.pro into your NIP05 and it will look like "sachin.npub.pro" nip05 in most clients, but whether they would find you with just a domain name is not certain, depends on the client.
Which nip46 servers support connecting with nostrconnect: schema? nak doesn't seem to, what about others?
I see next.nostrudel.ninja client has it, any other clients?
@fiatjaf@PABLOF7z@Mike Dilger@greenart7c3
"no clear incentive" argument doesn't cut it, never did.
There is 100m self-hosted sites on the web, and owners _pay_ to host every one of them. Their incentive is their business/hobby/etc. On Nostr, creators/businesses have the same incentive to run their own relays and to pay for good relays to have their notes delivered to followers. There would be at least 10m relays if Nostr got widely adopted, not counting all those phone relays serving as local caches.
Creators pay for web hosting. Creators will pay for nostr relays/media-hosting/etc.
I know free social platforms made this a bit non-obvious, but please look around the web. Hundred million people and businesses pay to have their own online space. Nothing new here.
Social media is no different actually. Creators making money on social spend enormous money to produce/promote/support their content, adding 10-100$ monthly to have their own relay to make sure their followers get their content is a rounding error. Blue checks are the proof of this.
Median user OTOH isn't going to run public relay/p2p-thing on their phone, that's 100% certain. That's where there is zero incentive to waste battery and bandwidth and space to "support the network" where all you do is scroll through memes for a couple minutes per day, when there are alternative apps without built-in relay that don't produce that waste.
Readers aren't going to pay for the network. Creators will.
I'm guessing the misconception is that all those creators would run public free open-to-all relays and face huge scaling/moderation/legal costs. That's obviously a bad idea and won't happen.
But does an average wordpress site have "comments"? Yes. Does author have to moderate those comments? Yes. All blogs are already tiny "relays" that have some costs that creators pay for. Again, nothing new.
If nostr is adopted, creators will have relays to host their own content, and to host legit reactions to that content - other events just won't be accepted. It will require some moderation and some costs, but that's a completely different thing vs managing a big public relay.
And outbox model will deliver you the twitter-like experience even though the content is scattered across a hundred relays hosted by creators you're interacting with.
Will there be big relays? Yes, twitter will run one, meta another. Will creators rely on them? No, not exclusively. Creators will run their own, that's the whole point.
And if DNS/hosting provider kills their relay, they'll just rebroadcast their stuff _everywhere_, until they set up a new relay in a different place.
Thanks for coming to my TED talk, as they say.
Automatic pay-per-use is nice idea and I want it explored, it just hasn't been built yet, so it's hard to predict how that will factor in. My point is that it's clear who has the incentive to pay for relays - creators, by running a relay or by outsourcing it.
Can you please expand on "connection oriented networks carry a few overheads wrt scalability"? I didn't see anything related in the linked doc.
Is there any w3c doc specifically about web's scaling/caching architecture/principles?
Also do you have any suggestions of how nostr's cache architecture could look like?
It seems like connections on nostr are not too "stateful". All messages sent to the socket could be sent each in it's own separate connection, concurrently, handled by different caching replicas of the same relay or different threads of the same relay. There's no session/user-level state to coordinate and synchronize btw replicas/threads that could harm scalability.
Oddbean new post about login | logout
Notes by brugeman | export
Also, batching filters might result in unintended expansion of result set - instead of 2 filters {npub1,kind1} and {npub2,kind2} sending one {[npub1,npub2],[kind1,kind2]} may return much more than was needed. So it seems like relays should allow more of precise (smaller?) filters.