Nostr Web Client

Yeah the same concerns apply to that NIP. I can see where this is coming from, but I disagree with the proposed solution (it sounds like someone was trying to reimplement mastodon silos inside nostr).

I mean, what’s supposed to happen if some client pulls a bitch@ and starts sharing events with nearby peers?

Sounds like that is an attempt to address the very real use case of “closed-ish communities”, and that I believe can be done in a better way than mimicking mastodon silos, thanks to nostr identity scheme and all the jazz.

Really it’s about keeping relays as an optional entity we use to conveniently relay data rather than soft enforcing some arbitrary policies.

Anthony Accioly 4mo ago 💬 4

I think the real mechanism regarding “privacy” and siloing community media is AUTH. (I’m using quotes here because I honestly don’t believe any kind of real privacy exists on social media, even with encryption, but that’s a hot take of mine.)

nostr:nprofile1qy2hwumn8ghj7mnfv4kzumn0wd68yvfwvdhk6qgswaehxw309ahx7um5wgh8w6twv5q3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7qgkwaehxw309aex2mrp0yhxummnw3ezucnpdejqqg9fgd8wze0dqxegd0k0cfm3autst56n05z3kwrj3zycesqdtjy9hctgqjfy has torn my idea apart in a way I probably couldn’t have done myself (unfortunately, the discussion thread has fragmented because poll support on Nostr is terrible):

nostr:nevent1qvzqqqqy2upzp22rfmsktmgpk2rtan7zwu00zuzax5maq5dnsu5g3xxvqr2u3pd7qys8wumn8ghj76rpwejkutnpvd3kjmmv0yh8xmmrd9skctmfde3x77qprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qpq9fl3yzd0ffnpy3mx9ukge7fs9dwrtkarkkwtjcs2t6qye7jcf8cskvwja8

He’s right. Just like NIP-70, “protected” events are really just asking people to respect the original uploader's intent. In other words, marking media as protected is just a statement of intention; people can easily ignore or bypass it. Still, this can be useful for well-behaved Blossom implementations run by well-intentioned folks, i.e. those mirroring to genuinely help. Marking a blob as protected is simply a request for other responsible Blossom users, nothing more.

Reply to this note

Please Login to reply.

Discussion

Niel Liesmons 4mo ago

Oops, didn't realize how dear the idea might have been to you. Might have been a bit too straightforward / brutally honest.

That said, there's a big "Why not?" for adding a protected tag anyway. It can only help. Just can't rely on it.

Anthony Accioly 4mo ago 💬 3

Nah mate, your take is not only valid but very welcome. I wouldn’t have asked if I wasn’t looking for an honest answer. And yours is well-embased, coming from someone who not only understands but is actually building with Blossom.

I think I’m ultimately trying to solve a people’s behaviour/expectations problem with tech, which is always a bit silly.

The core of the problem is:

Nevertheless, if there’s enough interest (and nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9emkjmn99urf278z doesn’t dislike the idea), I might still try to write a small optional BUD. But I’m not sure if it old help. What we really need is a better way to explain and educate both devs and users about Blossom. I’m trying to do something on this front as well.

Technical Debt 4mo ago

Feels like we need some sort of community groups/forums sort of thing.

And/or snapstr/nostories with proper encryption (at least for a “close friends” mode etc).

That way you keep relays decoupled from the distribution policies themselves (I mean, there’s no incentive for a relay to host something none of its users can reach).

Anthony Accioly 4mo ago 💬 1

You’re looking at solutions for a different problem here (restricting notes or media so they’re only served to a group). We already have the base mechanisms to solve this in both Nostr and Blossom (auth & encryption). On the end-user side, Nielson is currently working on Communikeys. And a large proportion of Nostr devs are working on NIP-29, Signal-like MLS groups, or other alternatives. I’m confident that one or more of these efforts will succeed.

The underlying ask here isn’t “don’t show my media to random folks.” On the contrary, people want to post publicly. They want kind 1, and they want it to be seen. But at the same time, they also want more control over how notes and media propagate.

I know, that’s a contradictory position from the start. But it’s the position of some users who see Blossom mirroring as the villain. And, for better or worse, that’s where “solutions” like NIP-70 and what I’m discussing here come from. The goal is to let users “restrict” (or at least signal their intent to restrict) mirroring, not access.

Technical Debt 4mo ago

I’ll have to confess, I made assumptions.

“They want kind 1, and they want to be seen.”

By whom?

“…they also want more control over how notes and media propagate”

Why?

So we’re in a position where some relay provides a mirror “for free/out of goodwill” and somehow we get an undesired outcome for some users.

If this was a jira ticket I would’ve asked for a user story/talk to the user because I’m not sure if either of us understand what is really hurting them (fancy way to say customers don’t always know what they want).

So while it could seem to be a “paradox” at first, “to be seen” and “to control the distribution”, it may actually be the case of “communication is hard”.

To be less abstract, my reasoning to untangle the “paradox” was that if the user doesn’t some notes to propagate freely in the network then there must be either a target audience or some “undesirable audience”. So that needed to happen at the npub layer, maybe adding cohorts tags to type 1 or close friends lists or bounded outboxes (i.e. I could add language and subject tags to my notes so that I could have my notes compartmented into multiple virtual outboxes or whatever that people could selectively follow, idk. Sounds like a completely unrelated idea but I think I like it).

Another possibility would be that the user understands deleting stuff from the internet is harder the more said content is replicated since deletions are in essence a gentleman’s agreement, but if that’s the case then the proposed solution of adding another optional request to not redistribute said content wouldn’t address the issue, risking resiliency for little to no tangible return.

Niel Liesmons 4mo ago 💬 2

And I agree with your 🌶 take.

I looked in the MLS, Signal and other encryption options for way too long to in the end realize they are:

- not worth the UX trade-offs at all

- distracting users away from taking responsibility and host stuff (name one of these solutions that has good UX around relays and media servers)

- a bunch of security hype that ignore the weakest link (human members) and strongest adversary (uber-wealthy deceivers class) all the time.

Technical Debt 4mo ago

I want to piggyback on that.

Seeing some nostr based chat apps implementing group chats that rely on a single relay to work is the kind of centralization that “we don’t really need”.

Federated protocols such as activity pub shift the “sovereignty” away from a single big centralized entity into many little but still centralized entities but nostr takes it a step further by bringing sovereignty down to each and every individual npub.

So tl;dr: don’t “give away power” to relays, build features for npubs

Anthony Accioly 4mo ago 💬 1

I think Niel here is working on the answer you’re looking for. I’m of a different opinion on this one. Relays are just like clients: as long as they’re light and easy enough for common folks to run, I have zero issues with them.

I do prefer some separation between client and relay (i.e. I think the Nostr model is better than ActivityPub on this front, and I’m not a huge fan of things like Ditto; even though I admit Ditto is how I first heard about Nostr).

However, if relays are absorbing some of the complexity, that should make things simpler for clients not just in theory but in practice. That’s not really what I’m seeing with some NIPs. Still, it’s early days, and I’ll keep experimenting until something works for communities. So far, I know that closed, auth relays work well for communities, but I’m also bullish on at least three different alternatives with varying degrees of dependency on specialised relays and backend components.

Technical Debt 4mo ago

I think the only thing that can flare up more relays is economic incentives.

If we treat relays like bitcoin miners, for instance I don’t need to pay a monthly fee to a specific miner so he (and only he) can put my transactions into the blockchain, then it shouldn’t matter if a raspberry pi in Indonesia or nostr.build relays a given bit of something, I mean come on, we have lightning, it should be possible to arrange some micropayments sort of thing.

Regarding client complexity, it doesn’t appear to be much of an issue given we have some varying uses of the nostr protocol which don’t really need every single feature to work.

We didn’t have complex access control rules on Twitter. Mastodon kind of brought up this sort of entanglement between “here lies a community of likely minded people shouting into the same void” and “this same set of people have a server in common” but that’s just an “accident”, and they are forever bound together (just like with every federated protocol).

For them, “mobile accounts, server independent” is just a pipedream that shall forever be on the backlog. But we have npubs, we have lightning, we can do better.

Technical Debt 4mo ago

That’s a good hot take, but I don’t really oppose people wanting to build community silos, I just think there are better ways to do that without relying on “picking specific relays”, a true spof.

Basically, treating relays as cattle, not pets.