Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

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