Nostr Web Client

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?

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.

Reply to this note

Please Login to reply.

Discussion

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