Profile: 8b278ad8...
I use their Android Element client and room sync is way faster than it used to be, as demonstrated in the talk.
The UX still bothers me though, I wish it was slicker.
Yes, maybe people have experienced the horrificness.
There is a talk from earlier this year about how they are making an noble effort to improve the thing in their next version: https://fosdem.org/2023/schedule/event/matrix20/
You just might end up needing indexes, and the Nostr begins drifting towards becoming Scuttlebot.
Great interview! I loved how it came back to scuttlebot at the end. And the unanswered questions. I'm going to recommend this interview to people in the future who are trying to figure out this stuff.
I'm still watching the discussion, I just wanted to publish that first reaction in real time.
Paul Frazee is a front-end hero of mine since vintage Patchwork.
I wish I had his eye for design and UX!
"Paul Frazee is really the defacto architect of Bluesky." woah, really?
Vintage Patchwork + Scuttlebot was the pinnacle of the cathedral and the bazaar.
What is going on now could be mostly madness and privatekeyjacking
We should build a new protocol, called it Phoenix, make it an append-only replicated log of signed messages and be done with this mess that we've overbuilt for nearly a decade.
No of course Bluesky is not a scam. Maybe it's just designed by a committee?
I think the trouble is that, while they have an awesome team, they seem to have thrown out everything everyone has ever learned about building a decentralized social network.
It's like they took all of the years of over-development on Scuttlebot and IPFS and have only included the worst of it while throwing out the good parts.
Nostr is the opposite of this, because the initial messaging protocol is so amazingly simple. It's just signed posts!
Now of course if you read all of the NIPS you see the over-development thing creeping in again and it scares the crap out of the people who believe in this stuff.
The hardcore distributed social fans are disappointed because some of these Bluesky devs are/were our heroes. But now they're making this weird API and a DID format that is basically a coverup for them holding into your private keys for you.
Is that a scam? Well, it depends on if you're giving them money or not I guess, and how you feel about what they're doing with the money.
* had a different public key [...]
Anyway, the issue is a little bit wandering towards Zooko's triangle, but that's the solution I came up with.
On Bogbook awhile back I had someone coming on and identifying as @ev, which looked exactly the same as my handle, which is @ev, and then pretending to be me while I was sleeping.
The solution I came up with was to provide a small in-line public key hint:

After I did that whoever it was cut it out, because everyone could see he had different public key than my own.
The answer is to use encryption and assume that the data will be decrypted by the people in possession of the keys and once that happens the data cannot be taken away.
If you're trying to give someone a file, and then revoke access later, then you need to have a centralized system with a login. Even then you cannot stop them from copying the file via other means.
Yes, you are right, it is the issue with any info.
So you can encrypt a message to a pubkey, or encrypt a message to a shared key, but you cannot revoke access to that data after.
The only way around this is to link to some centralized service where the data is stored, and even then people can take photos and/or copy and paste the data.
Yah, it'll destroy Nostr. It's a simple fact that this keypair is not that keypair and that keypair is not this keypair.
In order to change that fact, you need to create giant indexes that check every single message to make sure that you aren't missing a delegation message.
It's better to use cryptography the way it works than to try and use it a way that it does not work.
Yes, reading the spec there seems to be a missunderstanding about how the distribution of encrypted messages works.
You can't revoke access to something once you've distributed it over a decentralized network.
A better solution would be to use your Nostr signing key to gain access to a session where the information is then sent to your computer. Then you can revoke access to the signing key at a later date if you need to do that.
Can we test it? I just tried it and could not hear things.