Alby has started to return a {created: true} object from webln.enable() calls, which is not in the spec (the spec says to return an empty Promise).
Now some websites are relying on that {created: true} object being present and assuming webln doesn't exist otherwise, which makes it so they won't work on any other extension or environment that correctly implements the webln standard but not the "Alby standard".
In this case it might be a silly example, but this is how protocols die.
what is the point of returning the object? also if enough people are relying on it, is it worth considering adding it to the spec?
The entire point of a spec is that you don't keep changing it in backward-incompatible ways.
the object spec could be added as "should" instead of "must." you still have the issue of other clients not implementing it correctly and treating it as a requirement, but unfortunately there's not much we can do about it outside of shaming them. 😄
Yes, that's true, everything is hard.
I think we need some sort of local validation per each programming language.
Nip01.validate(payload) . Naive aproach
Specs are hard to follow and no mater what you do there will always be room for errors (create-at, created_at, createdAt which is it as they are all correct) or misinterpretation
The proper procedure would be to propose it to the spec and allow the community to debate such an addition.
sure but the nips readme says one of the requirements for changes to the nips is for at least two different clients to have it implemented. so hy definition, you'd have to implement it first. or at least it's a reasonable way to do it.
the explorer disease
They must have hired some former Google and Microsoft engineers 😂
I spent long enough in distributed systems to learn that schemas, not specs, were the appropriate way to enforce backwards compliability.
A friend of mine launched https://buf.build/ just a bit ago. He's looking to bring Google's intetnal protobuf secret sauce to all.
Hmmm, interesting...
nostr:note1c5qg30s2hemy5cq6raxh04gdfv97s36uc2ekzgyad0ylefgd9dcsyvl7qq
I thought this is how standards are started and evolved? isn't that also how nostr does things?
Its how all web "standards" were created in the past
You mean standards exist to be broken by the biggest player so the ecosystem centralizes more and more?
Why is it Alby's fault? If something like this provides value (i.e. is implemented by clients) isn't it worth considering adding it to the spec now?
By not following the spec Alby is causing all other clients to break. Because Alby is the biggest provider everybody will assume that whatever Alby does is the spec and others will have to either follow or die. You might as well call it the AlbyLN standard. If that is not centralization I don't know what is.
You can do it, no one is going to stop you. But you can't also keep saying it's an open standard.
With that said, I know these things are hard and it's easy to make mistakes. Maybe you didn't expect apps to start relying on the {created: true} response and it wasn't your intention to break other apps -- that's one of the reasons why I'm pointing out this: to warn people about these small slippery slopes.
But from nostr:nprofile1qqsrxra3gv0lnkxz2pcxh0xuq9k4f9dr7azwq3aypqtnay4w0mjzmtqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5qq7dwn 's answer above I get the feeling that he doesn't care and thinks this is even good.
What value does this provide other than break other WebLN clients?
It’s completely useless. It serves no real purpose whatsoever.
So we got better things then alby on the way ?
There is absolutely no benefit to this whatsoever.
It's only needlessly breaking other less popular implementations when websites choose to follow this proprietary thing.
