Idk what shit infused weed @utxo the webmaster 🧑💻 was smoking when he removed amber login from wisp.
Login to reply
Replies (30)
I was also asking and got this answer:
View quoted note →
Amber login is the smoothest integration I've had to do in all my apps. Not sure what he's on about.
If you built a real client you would know
View quoted note →
Built several realer ones than wisp.
Ones that actually have users
Probably have more commited users on all formstr products that on your shit social.
Lmfao
All you do is cry and build nonsense. Done with your retardation. Blocked
They're paying ones too. What is WISP's revenue?
Interesting 🤔
Its out apps that are shit apparently
nevent1qqsd5n99yck87g7p7dgndglef5rpptt83nd6y78ssdj45qes0guwqlcxfl09e
Even if he built it absolutely perfectly the concept is just too janky, it's not a good pattern
And it keeps changing now we have some new v3 decryption that will also break clients? And we have to build all these happy paths when people decline permission for one event but not another
Anyway whatever fuck it
Would’ve been easier to have implemented key delegations instead?
Probably not, the autists would still treat these keys like bitcoin cold storage
Isn’t the whole point of delegation that you keep the master key safe and abuse the slave keys?
Yes. But autists gonna autist
i thought so. noone else did though
If I remember correctly all solutions to key delegations required changes to clients and relays so it was always rejected because people don't want to change things in nostr
If the delegation implementation has permissions like nip 26 it still doesn't fix the issue from utxo where the user rejects some permissions and allow just some of them
Correct me if I’m wrong but utxo was referring to the case where you have a sequence of events that need to be signed together but the user only accepts some of the events in the chain.
Allowing permissions by type should be way easier to handle.
On wisp it only sends one request at a time for the signer, there was a bug when the user rejected a permission it would enter in a loop and it would keep asking again until the user accepted
Doesn’t have to be in a chain
The best way for people to understand is to just build a client with hundreds of users with different devices and different signers and different versions then try to deal with the bug reports
But that’s still different from the case where the slave key has restricted permissions, right? Because then the app would at least know the limits of the key rather than relying on the randomness of an external signer’s outcomes.
Why is it a bad pattern to ask a user if they want to create data tied to their identity
The technical concept of how signers work on phones
Because in the words of utxo, "you're an autist" 🤷♂️
So if am messaging with someone who is using wisp, technically google may rug pull the user and get access to those messages since the keys are derived from google login right?
thats not a nostr client, its a literal twitter clone. why even build something like that
No you fucking moron that's not how it works
its a new pattern and instead of trying to solve the problem through good UX, @utxo the webmaster 🧑💻 is just being lazy
he probably wants his users to remain like brainless sheep and continue using the same existing shit instead of solving a problem
Now this is a great idea: View quoted note →
not google login