so if i understand this correctly, you don't want to see DMs, a critical element of social networks, functional on nostr because you don't trust other client devs?
please, sir, sit down
users are at the helm of this decision and they choose to use an app and they trust the app
are you second guessing them?
i think yes
You are missing their point entirely.
It's not that they hate DMs.
It's that DMs are encrypted and there are currently only a few ways of handling decrypting them.
1. Give the client your nsec so it can decrypt anything itself.
2. Use an external signer with "fully trust this app" enabled, so it will automatically approve decrytion requests from that client.
3. Use an external signer without giving it leeway to auto-approve decryption requests, but then you get spammed with potentially hundreds of requests to manually approve, based on how many DMs you have. Not unread DMs... Total DMs.
4. Have DMs turned off in the client by default, but the user can turn them on when they have determined they trust the client enough to allow it to auto-approve decryption requests.
The first two options involve giving a client more trust than you may be ready to give when first trying it out. The third option is incredibly annoying and renders that client virtually unusable.
nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpz9mhxue69uhkummnw3ezuamfdejj7qgjwaehxw309ahx7um5wf6k2tnrdakj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9usc5pxf was thanking nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7208x3z for making the 4th option available in his client.
bro, if i have the secret, i can encrypt all the things
do you want to also move reading encrypted messages into the signer?
please explain what you mean
maybe you, like all these other nostr client apps, don't realise that modern AES encryption schemes DON'T enable cleatext attacks
literally, if you actually understood how modern AES-256 encryption algorithms worked, you'd understand why i find this absurd
decrypting one message doesn't decrypt them all
please go read some actual fucking cryptography papers on what we have had for idk... 20 years...
also nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3e82efwvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz8rhwden5te0wdshgetvd35hgefwdpa8yep3xsujucm0d5hszxrhwden5te0vdex2ct5wghxummnw3ezuamfdejj7qgkwaehxw309akkcettw5h8yetpd3ujumr0dshszgrhwden5te0wfjkccte9e38y6t8dp6xymmvwshxuet59a5kucn00qqzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99sq3x8x and nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qydhwumn8ghj7en9v4j8xtnwdaehgu3wvfskuep0w3hku7gpr3mhxue69uhkx6rjd9ehgurfd3kzumn0wd68yvfwvdhk6tcpzamhxue69uhk6mr9dd6jumn0wd68yvfwvdhk6tcpr9mhxue69uhkvet9v3ejumn0wd68ytnzv9hxgtmjw5q35amnwvaz7tmpv36kcapwxyu8qmr4wvh8xmmrd9skctcqyztuwzjyxe4x2dwpgken87tna2rdlhpd02va5cvvgrrywpddnr3jyl4rtna please go read about how AES cryptographic systems work, you guys really don't seem to understand them, or at least, i assumed that at least Jon here did, i could be wrong
also, making it difficult for apps to access decrypted data destroys all possibility of having state
nostr:nprofile1qydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhhg6r9vd5hgctyv4kzumn0wd68yvfwvdhk6tcprdmhxue69uhhw6r9v96zu6rpwpc8jarpwejhym3wvdhj7qghwaehxw309a3xjarrda5kuetj9eek7cmfv9kz7qgmwaehxw309aex2mrp0yhxummnw3ex7cmtv46zummjvuhsz9mhwden5te0d4kx26m49ehx7um5wgcjucm0d5hsz8rhwden5te0v3shvefwwd6zuem9wfkkztnfdchkummnw3eqzxnhwden5te0v9j82mr59ccnsurvw4ejuum0vd5kzmp0qys8wumn8ghj7ctsd3skxetfde6xsetnw4hzumn0wd68yvfwvdhk6tcqyr7jprhgeregx7q2j4fgjmjgy0xfm34l63pqvwyf2acsd9q0mynuzhejwp6 please recite to me the issues regarding stateful and stateless systems?
without easy access to encrypted data, nostr can't have state without revealing it, liek nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzfmhxue69uhkummnw3e82efwvdhk6tcprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hsz8rhwden5te0wdshgetvd35hgefwdpa8yep3xsujucm0d5hszyrhwden5te0vyhxummn9ekx7mp0qyt8wumn8ghj7cn9wehjumn0wd68yvfwvdhk6tcprpmhxue69uhkxetvd3shytnwdaehgu3wwa5kuef0qyw8wumn8ghj7erpwejjuum59enk2undvyhxjm30dehhxarjqyshwumn8ghj7en9v4j8xtnwdaehgu3wvfskuep0w3uhqetnvdexjur5qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fga4clq5 's app does with nostrudel configuration, and in contrast to nostr:nprofile1qyw8wumn8ghj76r0v3kxymmy9e3k7unpvdkx2tn5dahkcue0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpzamhxue69uhkzarvv9ejumn0wd68ytnvv9hxgtcpr3mhxue69uhkvet9v3ejumn0wd68ytnzv9hxgtmkd9jx2mcprdmhxue69uhkvet9v3ejumn0wd68ytnzv9hxgtm5dah8jqgcwaehxw309a3hyetpw3ezumn0wd68ytnhd9hx2tcprdmhxue69uhhyetvv9ujumn0wd68ymmrddjhgtn0wfnj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qpqjlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3q02gkyr 's app coracle, which encrypts app configuration data
I mostly agree with this. Specifically why I dislike nip46's ability to use public relays, relay auth can't be trusted for client-side security.
I think remote signers (nip07 for desktop) are the only way we should be interacting with web clients. Which is the purpose of my app nvault. I will eventually add direct connection only-nip46 support with nip44 encryption only.
For me there is also the UX of opening a new app and having to accept 100000 message decryption requests, then add 200ms of latency per request. This is the main reason I stopped using coracle. I can't stand declining all the auth prompts.
The final issue, is most client's can't correctly handle exceptions thrown during nip07 requests and most of them lock up after I decline 2 or 3 in a row: Coracle, Primal, Nostter, ChaChai,
I just want to choose when to load my chat, not every social client need's to handle DMs, I can go to another client for that. Most clients are only good at 1 thing anyway and most of us just hop between clients to do multiple things because theyre all broken in some way anyway.
so, you don't want your app to decrypt the state of your account, ok
don't force that on everyone else
and don't assume that coracle's implementation isn't naive and doing work when it doesn't have to
i've quite kicked a hornet's nest here
good
because i know confidently how encryption works, i have been working with EC signatures and encryption algorithms for 8 years now
but don't bother asking me, of course, because you all know better
I don't want the app storing my data on public relays, regardless of the cryptographic nature. I'm arguing that the UX blows when decrypting DMs at startup.
If you want to ask me for a single decryption request when I load, that's better (ill personally decline it). But I also want the app to still function when I decline it because maybe I don't trust the app. It needs to be able to fall back to some type of local storage
Double checking here:
Let's say I have my own private relay (inbox). If I'm the only one being AUTH'ed on it, does the data it sends to a client need to be encrypted?
Or can it in theory receive encrypted messages, decrypt them, wait for me to open my chat app and send 'em over?
Clients and relays do not use any form of data encryption (defined in the nips) to speak with each-other, only TLS, TOR, and so on. This encryption is strictly for client data.
Are you suggesting storing plaintext client data, in a private relay, so that it could avoid that UX hassle?
I would love for clients to have that fine grained control over relays. Personally I'm mad and I'd like for every note signed, the option to select which relay it gets sent too.
Yes, that's what I'm suggesting indeed.
The incentive for users to have their own relay is already huge, even without this.
Hmm. I guess I would be inclined to avoid calling it a relay, because it has a very special purpose. You're basically looking to standardize a personal database api.
You'd probably want a way for the client to challenge the server (relay) before trusting it, which we don't have a spec for either.
We'd also want those relays to be local only, so that unencrypted data isn't sitting in plaintext on anyone databases.
I don't want my private relay (or server, indeed) to do only that specific thing though.
Neither do I want to set up fifteen different private relays, each with their specific purpose.
I want my server to challenge the buggy clients, lol 😂 .
Were just describing things like firebase lol. There are specs for http based abstract databases. It could be a standard. Call me lazy, but I'd rather client developers build this type of caching on their own, because if it's a standard its probably going to suck.
I've developed a framework for this exact purpose for my own apps
it just lets web client's store arbitrary data with a standard http endpoint. It can be protected by authentication and other stuff. Thats how all my apps store user's preferences. In Nvault I use to store all sorts of client-side data for every user. I use it for website whitelists, permissions, and so on.
> the option to select which relay it gets sent too
Yup, I've been breaking my non-dev mind over where to propose this crucial feature in the NIPs.
Needs:
1️⃣ Npub can specify what relays an event is targeted at
2️⃣ Npub can edit this relay-set later on
An h-tag with the target relay, such as Chachi and the NIP-29 complexity lovers use, can only do the trick if the tags are editable after the fact.
NIP-70 does this in the best possible way.
With this, how does the author say "this event is targeted at these relays"?
This NIP asks relays to reject events with a ["-"]. It doesn't help in specifying the target audience for the event. That's what I need. In a way that's editable. For any event type.
This is exactly my issue with how other clients implement DMs
However I am not opposed to implementing NIP-17 DMs in noStrudel I just haven't had the time to really sit down and work on them
because you don't think they are important, even though they are the backbone of all other social networks
