Certainly worth experimenting with. Not all event data is desirable to be so easily linkable - p2p could help. But maybe event another sister protocol would be ideal using privacy preserving tech like mixing, etc.
One downside could be that if you pay a relay to persist your data, and they can’t easily identify or link data back to your pubkey, they can’t know to persist it.
The concern isn’t around public keys needing to be private or even anonymous - it’s more targeted toward publishing lots of event kinds by default (without opt-in, or even not being obvious is client UX, including new ones), when all I actually want to publish are kind 0,1,3,7,42,1984,etc (profile, notes, contact list, reactions, channel messages, spam reports, etc).
Pubkeys may be cheap, however I’m not going to create 100 just to segment or try obfuscate my data. Pubkeys if stored correctly, shouldn’t be throw away use for people - unless that’s their intention.
I have no issue with 1,000 NIPs that may content private/sensitive information being drafted - that’s 100% fine - the issue is that data being published by default by client apps - and not opt-in and clear in UX.
What’s long polling? The payment processing confirmation page after payment?
At first I think POW of 15-20 is fine, which is pretty quick on a server to return. I wouldn’t want the service to be for vanity high POW.. just as spam prevention available for lower power or mobile devices.
Unsure the payment API response times.. so again, maybe task id makes sense. Will have a play.
Relays are definitely in a unique position as they see the volume and have the most data to make decisions. Especially aggregators.
Client explicit filtering is hard especially for mobile devices. Explicit content detection for images may be ok, but videos? Not likely.
Client filtering based on keywords, pubkeys, kinds, lists, relays, etc - the more simple yet powerful stuff - makes the most sense.
I’m happy to chat to any relay operators who would like a service for this.
Aggregators will have the best data to build and train datasets - and detect spam sooner than relays. It’s certainly a space where one can add value.
I feel like perhaps we’re being quick to try and decentralise everything and store all config, data or state in published Nostr events by default 😟
The cross app support Nostr enables is awesome - but it comes with an insane privacy cost. Worse than todays social networks. Are we building something worse?
A public following list is fine. But I want a private one too. I want private lists. I want private block lists or mutes. I want private bookmarks. I want private connected relays. And so on.
The current client app approach is basically ‘give the government a direct event feed for everything you do or have, in a nice standardise format for them to process’.
We really need to rethink the public first mindset in Nostr clients. Most data can be synced using iCloud or something that’s not public - and made public by choice by the user as needed. You can even store the data as Nostr events locally without publishing if you like that format.
Let’s not build a privacy nightmare..
Happens when someone mentions you in their DM convo, but you can’t decrypt it because it was encrypted for someone else.
Yep. I’ve found there are three tiers, the mega relays, the mid tier which are mostly syncing between each other and are almost the same in content diversity, and the lower tier where it’s mostly a small group of users only and typically not syncing from other relays.
It’s not a bad place to be for the overall network.. but next couple 10x growth jumps will likely destabilise that.
Yep. Can even be a websocket. I’m not fussy.
Yep.
Maybe I don’t need the receipt stuff.. I would know the pubkey of the event being asked to be signed.
So I really just need to know who made each payment. Pubkey and amount. Then it’s just record keeping.
Does that need bolt12?
Yep effectively.. I’m just not sure how zaps work in the details. Specifically identifying the payee, what proof the payee and payer can match.
I don’t event mind if someone pre-pays like 1000 sats, then POW requests just deduct or error asking for payment.
I’ve built a POC service API, but it would need payments or be unsustainable.
nostr_pow_service] POW 20 Request - found 23 with 2459568 attempts in 117569 ms
"0000013873755374eb63f781ee765525b84225ad06c8238fb422dd6df43bb305" - 23
curl -X POST 'http://127.0.0.1:3030/request/20' --header 'Content-Type: application/json' --data-raw 'EVENT_JSON'
If any client app wants to offer the option, let me know, happy to chat about the API/UX.
I’m slightly behind on what’s possible with lightning.
Is it possible to setup something like a lightning address, that’s reusable (like bank details) for a service provider?
Then someone can sent you a payment (like a Nostr Zap). They get a unique receipt that only they should know.
Then they can provide that receipt to the service provider and say I have pre-paid this request.
Basically looking for a single request API remote Nostr event POW service, where someone sends partial event, difficultly target and a pre-payment hash that can be verified by the service provider as unspent yet.
Its all a moving target and accuracy is against a random 10% sample of split data before training.
The real world testing is the last couple weeks where I’m seeing validated accuracy against significant volume - I pre-filter 6,000 spam events/minute at present.
Can it be beaten, yes. Does it prevent flooding or other spam attacks? No. But content based spam like email should have some level of manageability with spam detection models.
Yep. I agree.
I’ve been playing with POW for months now..
Obviously a remote POW service/API and a client that can call it. I’m interested in perhaps building this if anyone is interested.
Something that’s missing today is a clearer POW to $ calculation cost. If we can estimate that better, we know what to charge.