đ¤Śââď¸ words are usually put in the content area⌠so thatâs what we did⌠we put the link in the tag. Itâs a very simple change. It will take devs 5 minutes to change. You arenât understanding. Calm down.
nostr:note1gxxawzucu2lf7sxyjz6kphgxajmltxkpmdggmqfc09mp6phs50vs2tw5gl
There is convention to use the content only when creating a new kind. It does not mean you should retroactively change things.
Tags/content are not special
This is the same as the retarded NIP-04/44 change.
I am assuming this is done in bad faith as you have not released even a preliminary documentation that would have taken much less time to write than your replies
Excuse me? Go fuck yourself. If you donât want to use Airchat, then donât.
All we did was move the link to the tag (which is how normal posts work).
Then we added the transcribed text to the content area (which is how normal posts work).
Nothing is done maliciously. You are attacking me needlessly. GFY!
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!
Fuck off, learn how to read
nostr:note1lmeucqh2t9y2xusmsmz7rs3mj5h6jwdz5ulxxcy0qaynya9g8mjqsve4jl
explain to me what is the benefit of your change that you still have not clearly documented and is worse than just adding a tag
Itâs just how we built it. We couldâve added a tag for the transcript but clients would need to add it, which would take just as long as adding what we did. Same dev time.
One is a breaking change the other is not
Thatâs the point. We donât want clients to play it unless they support transcripts.
oh huh why are you telling people how to build their apps?
The point of Airchat posts is audio+transcripts.
If people donât want to support Airchat posts in their app, they donât have to. đ¤ˇââď¸
go make a different kind then
We did!
You guys just started attacking me before we even published it. Itâs absurd.
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
It is not proprietary you fucking idiot! Itâll be released soon. Youâre literally hilarious, yakbak was made as a clone of Airchat.
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
- we arenât a corporation
- we have basically no funding you twat
- go fuck yourself
my post did not say anything about you being a greedy corporation
it appears you have no intention to collaborate and I hope others realize this
you may continue development in your own isolated island
We made a new spec. People can adopt them, we will help them do that if they want to. You guys are just mad we didnât use your old specâwhich didnât have transcripts.
Iâm done arguing with you. We will continue on just fine.
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?
Airchat is not the same thing as YakBak.
YakBak is a poor clone of Airchat that doesnât have transcriptions.
you keep making this about you for some reason.
Youâre the one whoâs making it about you. Iâm just trying to build this app in peace.
me: *makes half a dozen suggestions to work together to maintain interopoerabilty and compatability across 6 different apps*
you: *no im doing my own thing*
i am DEFINITELY making this all about me. yep.
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.
That's why they're different apps, they do things differently. Maybe other apps would have added support for the transcript tag, maybe they wouldn't but that's for them and their communities, no?
Others apps can add the Airchat NIP if they want to. Yes, thatâs for them to decide.
Standards are different than apps. If we all make a standard then what's the point of even making it on nostr? Why not just use a private DB on a website and enable API access to your data?
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!
Tell yourself whatever story you need to buddy đ
Centralised backend .
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.
nostr:note1lmeucqh2t9y2xusmsmz7rs3mj5h6jwdz5ulxxcy0qaynya9g8mjqsve4jl
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?
Not using the same kind, but the note structure is the same except for that change. It is what it is. You can still sign in with your key and connect to any relay, which is already better than Primal.
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.
Putting a massive amount of text in a tag feels awfully awkward. We decided to make a new NIP for Airchat. If apps donât want to support it, they donât have to. Simple as that.
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/
this is a breaking change for the sake of a breaking change. to the protocol, tags, content, they are the same.
this can be implemented in a nonbreaking and forward/backward compatible way by just adding a âtranscriptionâ tag
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.
