the core downfall of mastodon is that every instance is an opportunity to censor potentially thousands of individuals on the grounds of vague reasons such as “in appropriate content”
their entire architecture is based around the idea that a single instance admin has the power to decide what its users are allowed to see, and you can’t easily move to another relay without rebuilding your social graph.
why people still use this protocol is mind boggling to me.
let users control their own feed ffs. Individuals and clients should have this power, not relay tinpot dictators.
It’s clearly an all-in-one solution. It doesn’t seem that it’s intended to be used as a standalone signer. I would totally use it if I could use it that way. Maybe thats coming in the future.
Right now you have to trust that the on-device key, bitkey, and their server is all securely separated. The whole point of multisig to me is to have compartmentalized trust, but bitkey seems to be using it mainly as a recovery scheme if you lose your device, since there is no seed phrase import step
I was at least able to verify that it is using multisig, but was only able to by sending a transaction, otherwise it’s all a black box and I have to trust them.
One thing you can’t deny is that if you trust that they have implemented everything the right way, it’s a very slick and simple solution for most people.
Would I recommend this for people looking to store their life savings? Probably not, at least not until it becomes more transparent.
This describes my programming journey as well. I’ve even described it exactly this way in the past (lego blocks)
Before functional programming a spent a lot of time refactoring and restructuring code. Functional programming teaches you to build composable programs (legos) where you can swap out bits so you never really have to restructure things that often.
It drastically changed the way I write code in every other language. Haskell taught me to separate pure code from effectful code, most languages don’t force this separation of concerns.
I still hate classes though and prefer PoD structs and functions.
Pablo is not right and I disagree with point 2 as well.
Having a fixed set of trusted relays is good for network performance and trust if your client isn’t hardened. You can just remove a bad relay if it’s malicious. In the gossip model you can’t and others can force your client to pull from any relay they desire.
Im not that worried about the network overhead if the gossip model, connections are pretty cheap, just a bit of state in the kernel. Maybe you would need some kind of LRU connection pool? I have yet to think about how to optimize this, but it’s not impossible.
@3bf0c63f continues to downplay the engineering challenges for the gossip model. Its easy to criticize us larger clients for not caring about decentralization, but its already very hard to make a performant client on mobile, and now we have to make sure our app still works in the presence of way more connections and potentially faulty and slow micro relays.
I’ve spent almost a year building an in-client relay just so this model doesn’t affect the performance and security of the app. I’m almost at the point where I can begin experimenting with this model only because of it. it’s a damn hard thing to switch to without a large amount of engineering, but we are getting there.