There’s a debate raging over in the Bluesky world about whether or not infrastructure providers on ATprotocol should be neutral carriers or if people running things like PDS servers should be able to choose who they host.

It’s an interesting read and worth thinking about. From a Nostr perspective it’s like arguing for a custodial system then being upset at the power dynamics that exist because of that.

I’m curious what folks think. I think the poster kicked a hornets nest, not understanding how communities of users react to being told what they should or shouldn’t do with their own servers.

Thoughts?

https://gist.github.com/burningtree/d4aa172470293bdf2939c993cf48bbd4

This is a really interesting solution to the Nostr login system from @npub1k7cns...
@naddr1qqsx...

My own solution to growing nostr was to build divine.video which has generated a lot of excitement by people who want to use it and don’t even know to care that it’s nostr. Do something you can’t do in other social media ecosystems. Divine works because we have nostr libraries and blossom and relays and a ton of other things. It was much easier to build on Nostr than building the entire protocol from scratch. But it would have been easier to build centralized than on Nostr, if we didn’t care about freedom and a permissionless future.

We are running a version of keycast at login.divine.video. I don’t think custodial keys are something most nostr users would like to use. And I think it’s vital that any nostr app works with non-custodial keys. The goal is to make it easier to onboard users. Think of it as the bitcoin exchange that bridges to tradfi.

We generate a bunker url so you should be able to use the custodial key to access most nostr apps. And you can take your key and ask the service to delete it. Yeah you’d need to trust the keycast server operator to actually delete it and not use it. But this is the same thing users face in any service that uses traditional non-key based accounts.

Do you contribute to building Nostr? We’re trying to make Nostr better for everybody, and one step towards doing that is a survey, listening to developers and contributors. Please fill it out, and share it on!
@nevent1qqs...

Yep, I worked on Yahoo Pipes as the project I did right after leaving Odeo(ne twitter)... Mostly my work was on unit and integration tests in prep for launch as I joined it late. It was cool, yahoo killed it... we could totally bring it back and make something amazing that was pipes meets nostr.

I use tons of social apps and in particular recently the video apps because I need to understand how they work for divine.video. Can’t make a good Nostr video app without understanding what works for people on other apps.

Instagram reels has decided instead of showing me reels in languages I understand they’re going very poorly AI dub everything in to English. It’s so painful that it gets me to stop my endless scrolling.

Divine.video uses nostr. That’s more important than always talking about it on my podcast. Some guests don’t know enough about nostr to have an interesting conversation.

The divine web app connects to relays beyond relay.divine.video mostly to get users kind 0 and kind 3 events, and lets you choose other relays if you want to look for short form videos beyond our relay. We aren't pulling in content from other relays and we're not encouraging our users to publish to other relays. If you're seeing reports from divine users on your content, then you or somebody else is republishing your events to our relay. I believe you can use the h tag to limit what relays will host your content if you don't want that to happen.

A cool idea would be a way for you to publish, using your keys, a list of relays you don't want to host your content, kind of like the opposite of the h tag, that way you'd have more agency over where your posts went. At the moment, you're welcome to send us something and we can manually block your npub from our relays if you don't want your events to be visible to divine users on the divine relays.

We're tweaking the moderation and content warning system, right now it's flagging a bunch of things as adult content which are clearly not adult content.

Divine is using the extension to nip-71 that Vitor and I came up with in terms of just a replaceable event type so you can edit the metadata about the content. You can use it for any content you want, including AI generated content. We are using the client tag, you can filter out divine content from your client or your relay if you want. We're not pushing the divine events out form relay.divine.video but i think there are folks running scripts that share them beyond our relay.

The filters for the divine app is we check and label any content uploaded to our blossom server or from events on our relay. We do let you add your own blossom server and change the relays, but we'll indicate that you're outside of the divine experience and in the broader open nostr ecosystem.

In the divine app, we're going to have it use labelers we provide, but with settings to choose others. I honestly don't expect these choices to be very appealing to existing Nostr users and would encourage folks to consume the content with other clients. We are curating what goes in our relay and our media severs. If you're not keen on how we do it, use other clients or use the open source divine app and make a version with different choices.

I'm not planning on changing the nip-56 tag to other, i think 'ai-generated' is a useful tag of content and if a second app supports it i'll submit a PR to update the spec. Innovation in nostr is not based on strict support of the spec, each app supports it as they choose, with a few core elements. If we don't extend it, try new things, add extensions, then Nostr won't evolve. In ATprotocol they've got strict schema validators and their relays and appviews will not accept signed events that don't fit pre-approved schemas. That's not really the Nostr way. There is no central nostr standards authority to complain to, it is a permissionless network.

We will see a lot more folks get upset like you are at seeing content reports until @nprofile1q... changes Amethyst to show content reports as a content report label. Right now it shows up as if it was a comment. If you don't want to see them, stop using the divine relay, use a client that doesn't display labels that way, or contribute to amethyst to change it's behavior. I don't really love that decision decision, but I do support each nostr app developer making their own choices about how to interact with the network.

So New Zealand got it's first Ikea today. It's national news.... last year we got a Costco which caused mobs of people and was national news for over a week. I know it's silly and consumerist of me, but it sure does make life easier.

https://news.google.com/search?q=ikea%20nz&hl=en-NZ&gl=NZ&ceid=NZ%3Aen