Nostr Web Client

nostr:nprofile1qqs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crspz9mhxue69uhkummnw3ezuamfdejj7qgjwaehxw309ahx7um5wgerztnrdakj7qgawaehxw309a5x7arjd9nksarwdamjumn0wd68yvfwvdhk6tct9vymn 🤔

cloud fodder 1y ago

As long as you don't get too excited about calling 'private' mode private cause it's just nip42 auth. This is not a telegram replacement.. only because nostr is designed to be censorship resistant. So you can clone a 'private' group just by joining it, And instead of screenshots you can just blast these events around as fully verified proofs..

So I don't see how it's much different from using a relay to air reply in global, other than it requires a whole new implementation of a smart relay.

That being said, I'm not really opposed to it, I could probably implement the spec for it for strfry proxy if someone gives me a reason.

The timeline thing says it's a hack to prevent notes out of context, but I hardly think that's all people use telegram for ..? Like, my post was within the last 50 posts, is that really that valuable?

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

how does that work? surely it's all on the client to put the right context tagging?

cloud fodder 1y ago

https://github.com/nostr-protocol/nips/blob/master/29.md

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yeah, it's private if the relay is run by moderators and private as far as the moderaters control it but of course permitted users can broadcast events

that will probably be a ban-worthy offense though, and end further access, it's kinda rude thing to do really

on the other hand the way i had a dual listener relay set up with inbound from a reverse proxy and writing to it from the client as cache everything that my client was seeing was going to become visible without me enabling nip-42 and i hadn't written an actual ACL yet lol

cloud fodder 1y ago

Ya I hate the word 'private' really in the context of this nip. Nothing is private. Especially on nostr. Except maybe NIP87 cause it's so complicated it actually might be private. (Keys rotating and giftwraps)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

even then, you can't stop screenshots

cloud fodder 1y ago

Yes but screenshots aren't signatures of stuff you supposedly said 😂

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yes but the client still has those signed messages, and are you proposing DRM or closed source?

nope, then everything that is shared is potentially public

this is a simple fact of the game theory of communications and secrets

cloud fodder 1y ago

No I'm just saying screenshots are fine, it's not a cryptographic proof it's just some mumbo jumbo pixels anyone can make up.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

but only the group would know it's not true if it wasn't, and could prove it

and the rest of the world can't know it's true, but you can't stop the user who makes the screenshot from inspecting their cache

cloud fodder 1y ago

True dat. Well, one way I've been thinking of is that the relay itself is the only one who knows who is who (who has authed). So you post, and it generates new keys for you on the fly for each message. So that narrows the trust vector to who runs the relay. Vs. everyone in the group.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

there's also this problem:

nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnvv9hxgtcpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcqyrtce5j8mt3m6yz6xrrpm2m23aak7zsxq4tjkzd4g3vncnq635lnk85e9se

cloud fodder 1y ago

It's all very interesting but I just wanna hear exactly why we need a special relay to do NIP29 when afaikt it's just an obfuscation that is easily de-obfuscated. Vs nostr group chats OG with simple mod capabilities.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

agreed, there is no advantage

double ratchet and MLS are what lets you keep the cat in the bag outside of the key that is leaked

cloud fodder 1y ago

Yes, or if you trust your relay operator not to leak, nip42 auth with infinite keys, prevents all this in one fell swoop. It's as private as big tech.. where the OPerator Is the trusted party. At some point, gotta trust someone. And I'm not saying it's me, it could be you. It's the community leader.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yes, there is two patterns of group messaging

one: you encrypt and send to a trusted central server (this is the IRC method) and they then encrypt it (usually via TLS) and send it to all the other clients - the encryption is just the connection, the raw data is all in the possession of the server operator

two: you encrypt each message you send to the group individually to each counterpart in the group... the cost in bandwidth expands linearly with the number of users, you also gain the ability to exclude group members from seeing your messages, and the others can't prove the authenticity of your messages to others without giving away their nsec

three: the MLS model, where the group uses a merkle tree style derivation scheme to generate a per-message key for each message that a central moderator can stop access of one user to it because they are the merkle root

four: to be invented

personally, i like two, because it lets me exclude people i don't want to read from reading my messages and everyone else can't out me without revealing their key and anything they say is hearsay otherwise

cloud fodder 1y ago

Yes and I *think 2 is NIP87...

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

the arguments against the user-side encryption scheme are simply the bandwidth costs

for each additional user, each user has to send another message to broadcast to everyone

there is probably in-between ways of doing this but the ability to prove authenticity is lost as soon as you start key exchange processes that are ephemeral or otherwise not computable without knowing some ephemeral random secret value and catching that key in the message stream

i think that the natural path of private messaging groups is in opposition to the growth of the number of members in the group

once you pass the dunbar number it's impossible to do it properly as a client side encryption and this opens up being able to authenticate the message and decrypt it without compromising your actual secret key identity at the same time

i think that it's worth making the cost of proving a message authenticity by forcing the breach of your secret key

because then everyone can decript all of your messages as well, it's like a three way mexican standoff

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

and yes, this is what nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc has been doing with double ratchet and also now extending to MLS

simple kind 4 DMs require you to leak your secret to prove authenticity as well as leak the content

so do 1059 and 1060s

the double ratchet allows you to constrain that leak to one message, and MLS lets you do that with a multi party message

being able to constrain what can be leaked by providing the secret is another factor in this

if you want to out someone who sent you a DM, you have to give away your nsec, as well

double ratchet lets you avoid that problem, and ironically this is called forward secrecy with revocability because you can change that secret any time and not compromise your primary root key

MLS lets that happen to a whole group chat

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

yes, i get it now tho...

private is not secret

secret is only one person knows it

private is two or more

once it's private, it can become public, if one person betrays the pact

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

just reinforces the maxim:

secret means only one person knows about it

once it's two people, it's only private, and private can be compromised, unless the other persons are deleted (pun intended)

everything that is private can become public

the only way you keep a secret is if the other person is dead

Tekkadan, ゲロゲロ! 🐸 1y ago

I have no regard for privacy mode outside of NIP-42 but I can't shake the idea that perhaps NIP-29 will become more relevant and desirable in the future. At the very least for segregating users within a relay.

cloud fodder 1y ago

Could be, but if you assume your relay has moderation capability.. then I don't see any diff from regular nostr group chats

Tekkadan, ゲロゲロ! 🐸 1y ago

I think maybe that is the real issue. We don't see it differently- because it's a UI issue, which means it's also a relay.tools API decision.

I will go ahead and say, the way you could view relay.tools as a start9 for Nostr, I like to also imagine it as a start9 for the web. The old web. Web 2.0.

Reddit format is a template. 4chan is a template. Google+, FaceBook, Instagram, TikTok, even traditional BBS forums, WikiPedias are all templates of distributed communication and information channels.

NIP-29 makes sense in some contexts. Relays are decidedly multi-purpose so I imagine NIP-29 would also be decidedly multi-purpose.

If I host a Nostr client that controls relays, then I am running relays, and working with teams of administrators and moderators alike. It would make sense for cliques to exist within the relays to maintain a sense of respectable segregation without relying on the authoritative hammer to come down.

ismyhc 1y ago

Yeah I’ll be honest, I’m only really interested right now in public groups. That’s the main focus in the beginning and agree that Nostr is inherently public. The goal really for Seer is to become a really good public group chat. I would absolutely love to see nip29 support in strfry.

cloud fodder 1y ago

What relay implementations are you testing against?

ismyhc 1y ago

Right now working with nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 and his implementation.

https://github.com/fiatjaf/relay29

I’m not sure any other relays support it yet.

Matt Lorentz 1y ago

Is this running somewhere in a way I can try?

fiatjaf 1y ago

How is it not a Telegram replacement? You can also join a private Telegram group and forward messages from there to other places with the full assurance (provided by Telegram directly) that these messages came from specific people in that group.

In any case, screenshots are enough in 90% of the cases, in other cases -- like if you have a Signal chat and people don't believe screenshots -- you can always do stuff like record a video of the chat screen in your phone or just show your phone directly, I don't know, none of this is impossible to break in the real world. Ultimately you have to trust the people you send your messages to or the people you invite to your secret group.

Also blasting cryptographically signed messages is probably not going to do anything in practice since you'll need a compliant client to even display them -- or you must be a hacker and essentially make your own client, which most people aren't and won't bother.

To me 90% of the benefits of NIP-29 are public groups though, just a way to segregate the conversation. NIP-29 started as just custom relays fit for the specific purpose of chat (as you say, the air reply stuff), but it turns out that that design is flawed in some ways, so the current NIP-29 is slightly better and more portable, more flexible.

cloud fodder 1y ago

Ah, interesting, I haven't used telegram that much so maybe I don't quite understand why people use it (or that it has these cross group quotes). I had assumed it was more like signal.

I read NIP29 again this morning.. couple things that stand out to me:

1)"Relays are expected to reject any events that contain timeline references to events not found in their own database". - This part is gonna be hard on the relay side, lotta extra stuff to track/query for.. (3 queries per new event, across the relays database). Is the timeline stuff completely necessary or can relays ignore that and just do ACL checks + not allow older events?

2)private vs. public. Calling it private may set an expectation of privacy.. better words to describe the differences between auth (read ACL) vs no auth (write ACL, open for read). Wish I could think of some other words. "public read, read protected"

3)To really get adoption in your group I think you would need a way to create an 'invite code' that has limited time expiry. Like how discord does (maybe how telegram does too?). Otherwise people will make the group open (which leads to more spam) or closed (which leads to more manual approval and people unable to quickly join). With a code, that enables the group to sign people up in waves..

fiatjaf 1y ago

1. Relays can ignore it (my implementation currently does ignore it, which is wrong, and I think it's a client choice to include the references, if the client doesn't include anything the relay should just accept it), but I don't think it's hard, you can keep the past x message ids in memory and check against that, no?

2. I agree, but I also don't think most people expect anything super secure when they see the word "private". That's probably the expectation of just a few nerds. I think clients can use different wording though.

3. That's easy to do, we already have a kind that is a request to join, we can just shove a secret into that. But, again, public groups where anyone can join do exist on Telegram and have huge adoption. I was thinking that relays could do some basic filtering of who is entering -- like checking if they have some WoT ties to other people that are in the group, for example.

cloud fodder 1y ago

Re.1 yes, that would be what I'd have to do to implement it in the proxy. That or do req/response to the backend (might actually be faster).

I'm trying to understand why the timeline refs though in the first place. It being so loose, would not really add much to "things being out of context" in a potential fork (because other events could still be mixed into the timeline and be indistinguishable from the original) When I start thinking about why it would be needed I can't come up with a scenario where this loose coupling is any better than just the created_at timestamps. Seems like it adds complexity that could be avoided. Relays can just have a small time window of 5-10 min. Overall, it seems like it is a fun experiment to have these references but with little benefit as it cannot be a true chain of events (where every event references the previous like a blockchain would), so I just want to point this out.

Aside from the un-necessary complexity it could be seen as a 'western version' of air replies. By referencing previous events, this could be seen as a reply (and treated as such by a client), therefore breaking the Japan social contract of air replying. It is rude to reference the previous events if it is seen as the expectation of a response.

If the timeline is optional (could vs. should), then I have no problem with it. As currently written it sounds like a requirement.

As for the rest, it does seem like 29 could be a useful pattern to get off the main kind 1 tracks and have a standard way of moderation/invites/group management.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

Event tag refs work like a Blockchain... Causality is proven by the asymmetric knowledge of the event id hash

fiatjaf 1y ago

Telegram is just a CIA or KGB honeypot, I don't know.

PlasmaGuardian 1y ago

Non-repudation can be solved by allowing the user to easily generate fake messages on their client

PlasmaGuardian 1y ago

Telegram was never private though