Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 85
Generated: 01:34:03
Login to reply

Replies (85)

That's understandable but breaks the standard and now I can't enjoy your voice messages as a non-iOS guy 🥲 What about making a transition script that the user can transition to A0? It could just query all the existing kinds and have a single publish to A0 to transfer past work then disappears once the user has published one.
2025-11-12 14:04:10 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
if you would have talked to me you would have known that i've always wanted to do transcriptions, since the launch of yakbak, this has always been a goal, but figuring out how to do it in a decentralized manner. i've mentioned this to nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 a few times. it's extremely disappointing that you had an opportunity to be interoperable with half a dozen apps that already support the NIP-A0 spec and instead decided to do something completely different and incompatible instead of updating the NIP or incorporating it in another manner like Patrick suggested. interoperability is supposed to be one of nostr's most powerful features. if developers do not work together or or communicate, then what's the point of having a shared protocol? we win by being interoperable. we win by working together. you can obviously do whatever you like since it's an open protocol, but sometimes you gotta use the sword and not go alone.
2025-11-12 14:11:25 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
yeah this is pretty disappointing. instead of using a standard adopted by half a dozen apps, we now have a new standard that no one else uses, when the existing standard could have been used in addition to new features or even updated to allow those features to be included in the standard.
2025-11-12 14:12:47 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
i think it would have been extremely helpful to discuss beforehand as prehaps updating the spec and existing apps may be beneficial. this NIP was discussed and changed several times before it was merged. maybe we overlooked an additional use case and it could be updated once again if this is deemed better.
2025-11-12 14:22:41 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
There is no such thing as a “normal post”, there are conventions, they are never universally followed, and “amending” a spec for the sake of amending a spec, in a way that breaks compatibility with all other competitors and has no real benefit is just questionable at best and malicious at worst. NOTHING CHANGES IF THE LINK IS IN A TAG OR THE CONTENT!
2025-11-12 14:23:30 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
okay. are you using the same event kind? perhaps it makes sense for all apps to make these changes and choose to not show the content if they want to only show the link audio. we've need to loop in all of the other app devs that we'd be talking about breaking changes as this would completely break old events and they would no longer show audio. maybe some regex kung-fu could be used to band-aid fix them on the client side. maybe you could submit a PR to NIP-A0 and we can begin this discussion?
2025-11-12 14:28:29 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
Oh my fucking god If your entire intention on Nostr is to build proprietary specs and force others to comply with how YOU do things, then stop piggybacking off of free relays that are being run by people for *interoperability*, and make your own centralized backend
2025-11-12 14:32:07 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
so you made a similar app to existing apps and features, but decided to NOT use the same event kind? that's like making a photo feed app and not using kind:20 images in it because you wanted to add a new feature. im trying really hard to understand and to work with you so we can keep app interoperability and compatability here for the betterment of nostr.
2025-11-12 14:33:58 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
then the apple’s lightning connector is not proprietary it checks all the boxes ✅ managed by a single organization with interest in control over the design ✅ little to no intention to cooperate, imposing specs preferred over collaboration ✅ attempted as a way to divide the ecosystem ✅ designed solely to serve the owner’s use case
2025-11-12 14:34:56 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
nostr has such an amazing chance to do something that no other social system has ever done, allowing developers to work together and build independantly. for that vision to come true, developers need to actually want to work together. we have the opportunity to make this meme continue to be a reality or make it a laughable joke of the past. https://xkcd.com/927/
2025-11-12 14:43:48 from 1 relay(s) ↑ Parent Reply
im absolutely mad but it has nothing to do with me. i'd be mad if you made a photos app and decided to use event kind 64 instad of 20, just because you wanted to add something that wasn't in the spec. it's uneeded duplication of work and makes things harder for not only developers, but users too. nostr is confusing enough as it is with 6 different kinds of DMs. why do we need 2 different kinds of photos and 2 different kinds of voice messages?
2025-11-12 14:45:50 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
These apps don’t have transcriptions. If we used that NIP, all the apps would hear Airchat posts without having transcriptions. That isn’t what Airchat is about, so we made a new NIP. This about representing what Airchat is about, not me or anyone in particular. You never used Airchat and merely cloned it in a janky app, so you may not understand.
2025-11-12 14:55:35 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
i made several suggestions on how i felt that we could remedy this and work together. you told me you didn't want to each and every single time i tried to do so. i was very curteous and kind. i can't extend an olive branch forever. at some point you have to realize some people don't care about the things you care about and move on. good luck Colby!
2025-11-12 14:59:13 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
The point is that you shouldn't make changes to the spec that don't result in changes to the UX, just because you feel that the data structure is cleaner. The reason is that making such a change means there is now new development work that needs to be done in existing apps to support your new spec. You keep saying, "it will take devs 5 minutes," but the point is that it should take them *zero* time wherever possible. Unless there is community agreement that the structures/protocol should be changed in a manner that isn't backwards-compatible, you shouldn't make such changes, because such changes just cause the app ecosystem to become needlessly fractured.
2025-11-12 15:14:28 from 1 relay(s) ↑ Parent Reply
In any case you will have to check for it or you think everyone will just follow the spec or that there will never be bad actors? Again making you work the same as just changing the nip A0 to have transcripts
2025-11-12 15:21:31 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
I understand this part from a convention standpoint but it ultimately does not really matter (tags or content is completely arbitrary at the end of the day). I agree with the people here that there would have been multiple sollutions to this situation, and plenty of room for coordination, that will also allow you to easily filter events that dont include a transcript. They might have come out a bit hostile out of the gate, but understand its mostly dissapointment. Also understand that Nostr only has 1 commons, which is not that of the servers/relays, something other protocols try and fail because its stupid. Nostr's commons is that of the immaterial (loose) coordination on standards. And we don't have a police, and technically you can do whatever you want, but commons only thrife when participants forgo immediate opportunity for the sake of long term accrued benefits. People see you taking immediate opportunity and see the opportunity cost of that action, which explains why they are not happy. I hope you can reflect and can come back to the table at some later moment in time.
2025-11-12 16:04:17 from 1 relay(s) ↑ Parent 2 replies ↓ Reply
Putting that much text in a tag just doesn’t make any sense, if we are basing what “nostr” is off of kind1 posts. When you say “nostr”, that’s what it is… kind1 mostly. All these other NIPs are fighting to survive. I don’t have to respect all of them. That’s the point of permissionless development. Audio posts are barely used on nostr, and nostr itself is barely popular as is.
2025-11-12 16:07:28 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
Well, it seems you took very little time reflecting. My 2 cents: The transscripts should be seperate events, that reference whatever event it is they are transscribing. This has a couple of benefits; 1: transscripts can be produced after the fact; 2: transscripts can be produced by anyone; 3: transscripts can apply to all sorts of events. It would allow your client to provide transscripts for voice events that appearently did not have any. This way your usecase can leverage stuff that is already out there, and other clients can ignore transscripts if they want to. This set-up will benefit clients that would want to provide a good experience for deaf people for example, that can now addopt this broader transscript standard. All a clients has to do, is also query for transscript events related to the stuff it wants transscripts for.
2025-11-12 17:42:51 from 1 relay(s) ↑ Parent 1 replies ↓ Reply