Nostr Web Client

As usual with Nostr, there are multiple kinds for polls, and each client will support a different one (or none).

# Kind 1068 poll (works on Jumble):

nostr:nevent1qqsg8rskddvp8r6hww0eaccpxrkd80wcfannwd7cmh45ym53kzt00ggut5ap5

# Kind 6969 Zap poll (works on Amethyst):

nostr:nevent1qqsxzjchxfp9m2x6t5wt2u5rqp6d346p0yqlwksr92wsea7x25tlt0gprdmhxue69uhksctkv4hzuctrvd5k7mre9eek7cmfv9kz7q3qa6we08n7zsv2na689whc9hykpq4q6sj3kaauk9c2dm8vj0adlajqxpqqqqdnj0jfw8k

If your client supports neither, just comment yes or no below.

Original post:

Hi folks, quick poll: would anyone want to have "protected" media on Blossom (i.e. media that shouldn't be mirrored or spread to other Blossom servers)?

Think of it as an optional BUD, similar to NIP-70 (https://github.com/nostr-protocol/nips/blob/master/70.md), requiring AUTH and either automatically denying mirroring of protected media or verifying that the media was uploaded by the same pubkey on the origin server.

#devstr #blossom #nostr #media #growNostr

Reply to this note

Please Login to reply.

Discussion

Chris Krause 4mo ago

hzrd149 4mo ago

I'm familiar with the kind 1068 polls from NIP-88 but where does the kind 6969 come from?

#noStrudel doesn't support any polls yet, but I've added support for NIP-88 in applesauce so at some point ill add the feature to the app

hzrd149 4mo ago

Applesauce example app with polls https://hzrd149.github.io/applesauce/examples/#poll/timeline

Anthony Accioly 4mo ago

I've created it on Amethyst. There's a closed PR with this kind here https://github.com/nostr-protocol/nips/pull/320 but I'm not sure which other clients support it.

The Tim 4mo ago

nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg just shows an attached “poll event” but you can’t do anything with it!

Technical Debt 4mo ago

I feel like this has great potential to backfire, by making blossom media restricted to a few relays you’re putting censorship resistance on the line, along with overall fault tolerance, decentralization etc.

Anthony Accioly 4mo ago

I don’t disagree. At least to the same extent that NIP-70 makes Nostr events less resilient, available, etc. The problem is that many Nostr clients are defaulting to Blossom as the “everything media” protocol, and people are using it for selfies, vlogs, and so on.

We can’t really stop anyone willing to replicate media. But I think a NIP-70-like arrangement would be a good gentleman’s agreement between “civilised” Blossom servers. I.e., the original uploafet declares they don’t want this media replicated, so could you please deny calls to /mirror. Of course, bypassing this is trivial (it’s not a DRM scheme or anything) and the BUD itselt would be optional. So, just like with Nostr, folks would be free not to implement it.

Technical Debt 4mo ago

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

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:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q 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.

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

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:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr 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

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

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

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.

Ingwie Phoenix (aka. birb) 4mo ago

Primal supports neither. woop! :D

Anthony Accioly 4mo ago

nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5, maybe Polls are a good topic for Nostrability :)

elsat 4mo ago

https://github.com/nostrability/nostrability/issues/220

Anthony Accioly 4mo ago

nostr:npub1cesrkrcuelkxyhvupzm48e8hwn4005w0ya5jyvf9kh75mfegqx0q4kt37c, polls would be a great addition to Nosotros as well.

Cesar Dias 4mo ago

Planning that 🫡

Ingwie Phoenix (aka. birb) 4mo ago 💬 1

How many Bitcoiners does it take to ratify a standart... o.o

nostr:nevent1qvzqqqqqqypzpm5aj708u9qc48m5w2a0stwfvzp2p4p9rdmmevts5mkweyl6mlmyqqs0h57t9r23wky68h5z8zevqqkn9k0efljkqacydw6zkyjwqt0644g84f5c4

Hakan 4mo ago

I think this question will affect my answer: Can other hosts copy my uploaded images without my request?

If it works with the same logic as Nostr, the answer is obvious 😁 I just thought this part was more static for some reason. Like pubkey control.

Anthony Accioly 4mo ago

In short, yes, they can. Just like with Nostr notes (where anyone can broadcast or republish your events to other relays, spreading your content virally through the network), in Blossom anyone can mirror your media to other Blossom servers simply by calling the /mirror endpoint. I don’t want to put words in nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr’s mouth, but IMO this is by design. Blossom was meant as a simple, permissionless, resilience and censorship-resistance first protocol. Basically, it's pragmatical IPFS without the P2P/DHT aspect and its complications. It’s meant to spread your stuff around.

And then, as usual, Nostriches decided to use Blossom as the everything-media protocol without users fully understanding it. So now folks are uploading selfies, vlogs, and whatnot, and some are complaining that their stuff is being mirrored without permission. Or worse, they are uploading their stuff without knowing that Blossom is and that the whole point is that it's meant to facilitate mirroring of stuff across servers.

So my ask above is whether we should have some way to mark media as “protected,” meaning that the original author’s intention is for the content not to be spread to other Blossom servers. As with everything on the internet, this would be easy to bypass, but it would at least act as a declaration of intent from the author. Compliant Blossom tech could then respect this, so that other Nostriches don’t unintentionally mirror a protected blob against the author’s wishes.

Good read on the whats and whys of Blossom:

nostr:nevent1qqs0nk034mpdjf9efxjshtpdns8guk9lvrzakvvuz95rp3x8mc7gwagzyrtp7w79k045gq80mtnpdxjuzl9t7vjxk52rv80f888y5xsd5mh55cap4rd

Hakan 4mo ago

Thank you very much for your detailed and clear answer as always.

I agree with what you said. Even leaving Blossom aside, anything put on the internet can be easily copied. In this respect, no such media host will offer complete privacy. But it's good that people have even minimal control over their own media.

For example, I was thinking "I may not be able to completely delete my notes, but at least I can delete the image I uploaded to different hosts if I regret it later and somehow disconnect it from my profile". If there was a feature like you said, I could upload some images like that. For most images, it's important to know that they won't be deleted later.

Hakan 4mo ago

Or it can be a site, an application that will send a deletion request to all known blossom hosts as in the notes.

Anthony Accioly 4mo ago

Agreed. Client side support for deletion is still rare, nak can delete blobs. I assume some blossom management apps can do this as well.

Agi Choote 4mo ago

Lol