I don't feel too bad though I think they have more users in LATAM than Lightning retail users in general, definitely more than Cashu and Fedimints And of course these actually pay fees to Bitcoin miners
🔔 This profile hasn't been claimed yet. If this is your Nostr profile, you can claim it.
Edit
I don't feel too bad though I think they have more users in LATAM than Lightning retail users in general, definitely more than Cashu and Fedimints And of course these actually pay fees to Bitcoin miners
If this is non-custodial then Rootstock is non-custodial. Yes they both are from a regulatory point of view, but the word is overloaded, and when you say the word Rootstock everyone dismiss it as a custodial trusted single point of failure, why not afford it the trust and grace we afford projects like Cashu and Zaps and flat out custodial Lightning?
I really feel bad for Rootstock, they had been running the most secure federated bridge for 8 years, in fact the only HSM based bridge with any track record at all, no theft no rug pulls no shitcoinry no nothing, sqweeky clean ... And still Bitcoiners decided to not care nor leverage it and instead build random anonymous Fedimints and Cashu mints instead. I am fine with centralisation for pocket money, but they could have been building more secure performance L3s while leveraging the smart contracts and the trust accumulation on the security of the Rootstock bridge and grow that federation and or contribute to a BitVM upgrade... I don't understand what is the point of ignoring all of that, what user is better off because of it? People are free to do things their own way, but I will keep talking about Rootstock until I figure out what is the blocker?
I am basically saying; the "signer" app could be just the devices you own, as long as they support passkeys. This was never an option with Pkarr, simply because you couldn't temporarily trust someone else to update your DNS records .. because there is no rotation, so you can't take exclusive custody later. We don't need that here, and in fact recovery keys in offline storage + a server, is safer than a non-rotatable keyon your internet connected device, even if we do great job encrypting it at rest
I don't trust liquid whatsoever and prefer to pay Bitcoin miners... I don't think there is any reason to believe Rootstock federation can't react, the HSM doesn't validate anything but PoW so all you need is miners to vote for a fork and all is good, you just need to keep the headers the same, any significant change in Rootstock headers requires a change of HSM firmware which requires miners to vote for transfer of all bridge BTC to a new bridge address. But you might have your own reasons.
But note; I am only talking about Authentication so far. The Ring signer app does more than that, it Authorizes access to the Homeserver. I can't tell how would authorization work yet because I am not focused on Homeservers at all, and not even assuming they will exist. But my assumption is that authorization is just a thing you do after you authenticate... So it could be that you don't need an app for that either, instead you authenticate to the Homeserver UI then manage authorization from there. Similarly if an app wants to ask for permissions from your Homeserver, it should know your Homeserver address from the Nameserver records, and it can redirect you there like apps redirect you to authorization from Gmail account. All in all, you might not need an app at all, if you are not managing any keys yourself... Recovery key written on a piece of paper might be just enough.
I mean think about it, passkeys usually work by you registering passkeys in the database of an account you already have .... Well why not registering these passkeys in your DNS records... In fact I think this should be doable in normal DNS except that; 1. Most people don't have domains at all. 2. DNS by default is not authenticated, and even if you use DNSSEC, you are relying on certificates by central authorities.
I don't know yet. My basic assumption is that for most users who don't want to have self custody they won't need an app, they will use a web app they sign in to with a Passkey and ask their Namespace to update their records when they need... So not unlike Bluesky in that regard. Possibly they download a recovery key that helps them recover if the Registrar and or Nameserver dies. If they try to take custody of their own keys, then the app could be an app that doubles as a 2FA app like Google authenticator... That doesn't do more than manage the identity. But another harder alternative would be something like Peergos app or Google Drive or Proton Drive, where you manage both identity but also access control in a central place. The later is obviously much harder than the former, and not needing any apps is easier than all. Simplest solution is to register your devices passkeys in your records in your Nameserver, and then sign in by writing your name, and the web app resolves your passkeys and prompt you to login with passkeys and check if the passkey you used is in your signed records
My plan for the POC for Mlkut PKI is a registration app that allows you to progressively gain more control of your identity; 1. Level One; a server that already registered a batch of IDs points one of these IDs to the endpoints you want, and allow you to update them using a Passkey. 2. Level Two; if you want to survive the server dying, you can download a recovery key. 3. Level Three; if you don't want to trust the default server with custody of the keys any more, you can either; A) Pay a Rootstock transaction fee to change the recovery key to something that the server never had. B) Move to another server, and let that new server pay the transaction fee, possibly by batching multiple users migrating at once. If you remain at Level 1, you are not too different from Mastodon. If you remain at Level 2 you are not too different from Bluesky (trusting DID PLC and your server not to steal your identity). If you go all the way to Level 3, you are just as sovereign as having Nostr Nsec + using bunkers + can fire the bunker if they try to steal your identity, but you need to pay for a transaction fee for that. The main downside remains that if you trust a server to custody the keys, you really need to get notifications if the server tries to steal your identity, by watching the Rootstock chan. In practice, most users will remain at Level One, but they have the option to upgrade their control if they care. And of course the ID is short enough you can enter in a username field from memory, and use a Passkey to authenticate a device, but that is advance demo from just registration.
Of course in practice, both your Registrar and Nameserver will be the same as the Homeserver, which in turn is most likely would be the default server of the developer of App you downloaded and possibly paying for... So really not very different from just buying a domain from a hosting provider... But you can move from their to a better more sovereign place... Or not! Which is by the way why Mlkut Homeservers and the rest of the protocol should support ICANN domains, if some people are hell bent on not having self sovereignity ever, might as well get a nice subdomain? But maybe encouraging this ends up being a big mistake.
Well then you better download the recovery key as soon as possible and back it up. And if you are afraid the server might rugpull you, then consider making an onchain transaction to rotate the keys to keys only you have, and not the server. Just because it is a Progressive custody scheme, doesn't mean you can't start from self custody too, but most people won't, not until they actually care about the thing they are going to take custody of, and it takes time before people get invested in their online presence.
Yeah of course, but think how insane this is, when all I want is to reply to you, instead of just sending you an email like sane people I am supposed to send a packet in the wind and hope for the best? Even for many to many, which is a very niche case that more or less boils down to Twitter feeds UX, who actually benefits from the insane bandwidth of that gossip? And storage? Who pays for all of that and why? Wouldn't it be infinitely more manageable and cost effective to have things like discord servers and Reddit and group chats etc? Nostr and Bluesky and Pubky (less so Mastodon because it is aligned with intentional messages passing) are simply intractable and can't both scale and remain decentralised... Because they chose a requirement that is impossible to scale.
Counting as a DAO would be an objective thing just like counting as a company, regardless of my opinion. And my opinion doesn't matter specifically, since I am not familiar with Defi much more very interested. I just want more orgs with some legal arbitrage to compete in the market, because if/when I need them, I want a non-kyc options as much as possible.
This is why you need to use an identity system where creating identities cost something. Email does this by blacklisting spammy servers so servers have to limit who sign up somehow. My idea for a cost is basically the Blockchain, basically servers buy a batch of rare limited IDs, and transfer them to users that they have to then audit, because shit isn't free. Of course a determined user can go to the Blockchain directly. I figure a rate limit of 100K users a day is enough to satisfy even the insane onboarding of Bluesky, while not actually have infinite IDs to burn. A friend request could be as small as 128 bytes or so, so it is hard to overwhelm a server by requests, and each one costs money, so a spammer is much better off with social engineering some other way.
Ungodly amount of text... More relevantly it is what Bluesky did (ignoring that the registry is fully centralized) and we know that only a handful of 40 millions cared to get any level of custody or recovery options... People don't care. But that's ok, they have the right not to. As long as the ones who do are empowered.
If you use the outbox model, and your few outbox servers got DDoSed you still have the same result as Mastodon here. It doesn't matter that you have 3 outboxes instead of 1 homeserver... You are either; 1. Using one paid relays which the same as Mastodon server 2. Using multiple free relays that owe you Nothing and have no promises of resilience. Nostr is not a reliable network it is censorship resistant network, somewhat, so don't shame people for having popular servers, that is user choice and they get things out of it that they consider more valuable than what you get from Nostr.
They won't arrive, your app will tell you that the posting succeeded because it arrived _somewhere_, but it would be like a tree falling in a forest without witnesses. You don't really know which posts got posted to primal and damus and which didn't. But in practice if you don't post to these two, potentially because they are under DDoS, you get worst of both worlds; 1. The service is not available (no one sees your post/reply) 2. You get no indication of failure whatsoever
Does Nostr fix this? Or are Nostr users already used to unreliable delivery, that it doesn't matter much when they send their data to an obscure relay that no body reads, while all the popular relays are busy?
Mlkut name system is going to be hard to explain... But I plan to use the existing analogies because they are appropriate; 1. Registrar; the entity registering a domain by making an onchain transaction. 2. Nameserver; the entity that the p2p network points to as the place where the corresponding records for a given name is served from, regardless of caching. Your Registrar can be your Nameserver You can be your own Registrar and your own Nameserver. Your can backup the keys in case your Registrar dies. You can rotate the keys with the cooperation of your Registrar to no longer need their liveness nor their honesty. You can let your Nameserver hold the keys that sign DNS records, or you can take custody of these keys, and only rely on the Nameserver for hosting. You choose how much do you care about your domain long term.
Working on https://mlkut.org, designer and maintener of https://pkarr.org. https://nuh.dev