Censorship-Resistant Multi-Instance Identities

[zyansheep]

Requirements

• [X] Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• [X] Did you check to see if this issue already exists?
• [X] Is this only a feature request? Do not put multiple feature requests in one issue.
• [X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Is your proposal related to a problem?

There are two main problems this proposal attempts to solve:

• The user's dependence on a single server. This proposal would allow users to be apart of more than one server and to move between servers to avoid a single point of failure for user data or other services.

• The inordinate control servers have over their users, managing users' entire identity as well as what user's can see of the rest of the network, and what they can post. This proposal would make it so that servers cannot undetectably censor any known user and cannot meaningfully impersonate their own users.

Describe the solution you'd like.

The solution I will describe here is heavily inspired by the scuttlebutt and polycentric protocols.

Instead of a user's history and identity being tied and stored primarily on a single server, any data a user generates (whether that be a post, comment, or profile update) is instead recorded in an append-only hash-linked indexed log (a "user history"), each entry signed locally with a private key controlled by the user, and distributed to a set of user-chosen instances. These signed and stored chunks of data can then be distributed by these hosting instances to other server's users in different contexts. Here's an overview of possible types of signed chunks.

• Post / Comment
  • If a user makes a post or comment, their client creates a new "chunk" containing roughly:
  • The hash of the previous chunk
  • The number of the chunk (counts up from 0)
  • ID of Post commented on or community posted to
  • Content of the comment / post
  • Signature, can be verified by public key.
  • The server then takes this data, and forwards it on to whatever server hosts the community that was posted in to be shown to other users when the post or comment is requested.
• Profile / Settings Updates
  • These are basically structured the same except instead of a post/community ID and data, it's just a diff between the old profile data and the new, which the server promptly updates in its database to show to any user or other server requesting this user's profile.
• Authority Update
  • If the user needs to register a new key, invalidate an unused key, register a server as a trusted for recovery, or mark a registered key as compromised, this is itself a chunk added into the user's history. This chunk is must be signed by a previously trusted key or recovery server.
  • Any other server can request this information to present comments or posts as belonging to a specific user's public key, as well as the validity/authorization status of that key (i.e. so posts made by compromised keys can be marked as such to users)
• Username Recognition
  • This protocol doesn't outline any kind of global username consensus algorithm, so it keeps the existing system where usernames are associated with servers, but extends it so that a given user may have multiple usernames on multiple different servers. For these purposes, the proposal includes a chunk "username recognition" chunk jointly signed by an instance's main keypair and a user's client keypair signifying the instance's commitment of giving a username to a user.
  • This makes it very obvious when a username is given to a different user, and shows the history of a given user's name across different instances.
  • Instances may also use this mechanism to prevent a user from having multiple different names on different instances, by only allowing a user to register a new name if they do not have any previously registered names.
  • Username history could also be used to prevent a user from trying to register a username on too many servers, to avoid requiring servers to unnecessarily maintain long lists of users. Usernames could also be "collectively claimed", whereby if a username is registered to multiple trusted servers, new servers won't allow registering other users with that username. Servers may independently decide whether to federate with other servers that respect/disprespect this policy.

This is just my general idea for a solution. There are lots of other details around aspects such as the specific crypographic primitives but I want to see what people think of this proposal first before addressing the more nuanced design or implementation details.

Describe alternatives you've considered.

What I'm proposing here is kind of an comprehensive version of what has been proposed in other issues:

506 (manually exporting/ importing account data from/to different instances)

3164 (auto syncing user data across instances)

1985 (moving an entire profile to a new instance)

This proposal would solve the root cause of all these issues: there is no need for migration or syncing users if there is only one user distributed across multiple servers! It would also solve issues like cross-instance bans (https://github.com/LemmyNet/lemmy/issues/3399 ?) and anything else that relies on associating data with an identity across instances, because you can just associate the data with a public key instead of a specific account on a specific server. Even if a user tries to ban-evade by changing the public key and username associated with the account (while keeping the same comment and post history), it would be easy to tell for the server that banned the user just by going through the history of keys in the account and checking them against the banlist.

Additional context

Related issue: LemmyNet/lemmy-ui#1571 (cross-instance syncing & linking feature request). I commented a shorter outline of idea there, but then I figured I should open a more comprehensive issue on the main repo because it is not a ui-specific issue.

Edits

7/7/23 - Updated proposal to include multiple key idea and username recognition idea + other small edits.

[mvdkleijn]

Sounds to me like you're basically proposing to stick user data in a git repo, just append-only and having commits signed by default.

[I-Knight-I]

any data a user generates (whether that be a post, comment, or profile update) is instead recorded in an append-only hash-linked numbered log (each entry signed locally with the user's private key) and distributed to a fixed set of user-chosen servers. These signed and stored chunks of data can then be distributed by these hosting servers to other servers in different contexts.

What if someone posts something they regret, that's confidential, personal, illegal, etc? That content is then immutable and replicated across multiple servers; essentially made permanent, no?

[K4LCIFER]

Signature, can be verified by public key.

Signing of posts and comments is a must. As far as I'm aware, currently, server admins with direct access to the database can manually modify the content of user's posts, and comments without their consent.

[zyansheep]

any data a user generates (whether that be a post, comment, or profile update) is instead recorded in an append-only hash-linked numbered log (each entry signed locally with the user's private key) and distributed to a fixed set of user-chosen servers. These signed and stored chunks of data can then be distributed by these hosting servers to other servers in different contexts.

What if someone posts something they regret, that's confidential, personal, illegal, etc? That content is then immutable and replicated across multiple servers; essentially made permanent, no?

That is already kind of the case afaict. Posts and comments are distributed around to servers who have interest in them, and while you can request for servers to delete content, there is nothing forcing them to do so. It is the same in this situation, you can request servers to delete or stop distributing one of your previously signed data chunks, but there is nothing forcing them to do so. The only difference is in this system it would be very obvious to any server owner that cared to go through a user's history and see that the user requested certain chunks to be deleted, or that certain chunks are not being distributed by other servers, making it easy for archivists or dirt-diggers to know at the very least, the hash of hidden data blocks.

It might be possible to forgo the ordering altogether on certain types of data to make it more like the current system, but then that would open you up to servers being able to undetectably censor a user's content. There might be other ways around this, such as some kind of mutable merkel tree that maintains a list of all a user's posts and comments (controlled by the user), and that might be a desirable strategy, but I haven't theorized about that kind of solution in-depth. There may be significant memory overhead...

[zyansheep]

I saw a few a comments from a recent related issue (#3476) that also partially apply to this one and I think I have some ideas to address them.

@sunaurus's comment

In general, instance admins can run whatever js they want on their instance, so it's quite impossible to ensure that a malicious instance admin would not just harvest private keys from users.

Even ignoring that main issue, having such a system would mean that:

• 3rd party app setup will become much more difficult (users need to figure out how to import their keys into each app)
• Signing in to a new browser would require users to have their private key ready
• User account recovery would no longer be possible
• Average users probably wouldn't really understand this system

The problem here seems to be that all authority over a user's account is government by a single shared (stealable) private key. One way to solve this would be to split authority up between devices and even certain trusted servers, where each new device generates their own keypairs (like on Matrix), and if user wants to make sure they don't loose access to their account if they loose their devices, they can create their account such that the "trusted public keys" of the account can be changed by a special keypair encrypted on a server with a password only the user knows (or any other kind of recovery scheme one could imagine where the server temporarily gains, or permanently shares with other servers, power over a given user's account). All this could theoretically be hidden from the users with decent defaults in place, while allowing more security-minded individuals to customize the exact access semantics of their accounts.

@0xAnansi's comment (some parts)

Anybody that ever used PGP can acknowledge how painful it is to change your key btw, so if any user loses his key, has a stolen one, or for any reason needs to change it, good luck to him. Also, for PKI, you just change who you need to trust to ensure integrity of the data, and you'll most likely end up with a cartel similar to the one that ran for decades concerning SSL certificate emissions.

The PKI here would simply be a declaration in the immutable history of the user of what list of keys are allowed to write to the history, and what kind of recovery mechanisms should be used. It avoids the SSL problem by allowing users and servers to scrutinize the full context of what the roots of trust for a given user are (how many devices? what permissions do they have? what servers? what recovery mechanisms?), rather than just trusting an arbitrary list of certificate authorities. If any user is ever suspected of being compromised, the user history contains all the information needed to try and figure out what might be happening, and for the user to make their case that their keypairs are the ones that should be trusted and not the hacker.

And lastly, you'd need to use a client that is not served by the instance owner, which atm is far from being the norm, because once again, the verification could be just faked anyway by the instance owner.

With each client having its own keypair, some clients could still definitely be compromised by various means, but this is not as hopeless a situation as it might be with only one shared keypair. If a specific user client is compromised, the compromised client can be removed from the keylist via recovery mechanisms managed by various servers, or by some amount of other clients associated with the user's history overriding the compromised client's attempt to modify the user history. The name of the game for this multi-key system is splitting the authority over a user's history among many different devices and servers, while preventing any one point of authority from doing irreversible harm.

[WayneSheppard]

Where do you plan to store all these public keys? Are you suggesting that Lemmy builds out their own PKI?

[eeriemyxi]

Where do you plan to store all these public keys? Are you suggesting that Lemmy builds out their own PKI?

They are "distributed to a fixed set of user-chosen servers." So I think they meant Lemmy instances should have the capability to store public keys.

[ghost]

I think blockchain based domains are a significantly better solution. Some reasons for why they would be a better solution include

• They can be controlled by organizations by computations on chain
• There are chains today that secure billions of dollars in total value locked. (With Ethereum currently having the largest total value locked.) Users can be confident that their identity storage is just as safe as any other contract on the foundation of the chosen blockchains.
• They already have high usage, with Ethereum Name Service having over 2.5 million registrations.
• Users who do not want to register a name could use a blockchain address instead for free.
• They're already integrated well, with Metamask and Brave Browser supporting them.
  • MetaMask has over 20 million monthly active users
  • Brave Browser has over 50 million monthly active users.

[zyansheep]

@fLgI6FeL02hKr2g4qBj0hEfN4VvA6TpN Is this proposal and alternative to the account synchronization proposal outlined at the top of this thread? Or is this solely a proposal for universal name registration?

If it's the first: How does this work on a technical level, how would this work across devices, and how would account recovery work? If you loose your blockchain private key, are you basically screwed or do these providers have recovery services like I proposed for this issue? Would Lemmy servers have to also interact with (and store) the network & blockchains of whatever one is chosen, or would they be relying on the 3rd party services to do the blockchain interaction for them?

Also, to register an account on the blockchain so that it is portable across lemmy servers (I'm assuming this data would just be like a public key or something for identity, not constantly registering things to the blockchain), doesn't that require money that users would have to pay for? No matter how low the fees are, that's going to be a much higher barrier to entry in comparison because users would have to create an account using a provider... blockchain auth might be useful as a recovery option or something, but I'm not sure exactly sure how it would be a significantly better solution than the proposal outlined in this issue.

If it's the second: Blockchains are pretty good at name registration, so I think this is a good idea (but the relevant issue should be renamed to be more clear).

[ghost]

Is this proposal and alternative to the account synchronization proposal outlined at the top of this thread?

Blockchains like Ethereum serve as finalization networks. They're trusted, they have so far had high reliability. They do not require new networks to be created. They secure billions of dolllars. A system for proving post history could be created that has the state saved on chain like higher layer chains that already provide proofs back to Ethereum's main chain.

Or is this solely a proposal for universal name registration?

It is both, but in my opinion, a very strong and censorship resistant identity system.

How does this work on a technical level, how would this work across devices, and how would account recovery work?

It's actually a really nice solution, as domains are provided as NFTs to addresses that are either contracts or accounts. This means that users can choose custodial services for themselves if they desire to use them. They can also have extremely complicated blockchain based contracts that control how recovery is handled.

Would Lemmy servers have to also interact with (and store) the network & blockchains of whatever one is chosen, or would they be relying on the 3rd party services to do the blockchain interaction for them?

It sounds like the solution proposed here was a custom solution, where a solution with existing chains could just rely on mostly created solutions. It seems like many applications are using RPC calls to different public nodes. A simple case would be to just think about the Ethereum blockchain for a moment. On Ethereum, there's a contract that handles ENS domains. The state of the contract determines whether or not an address controls a domain. Addresses on Ethereum are already associated with public and private key pairs. There are many options for retrieving this data safely.

doesn't that require money that users would have to pay for?

If a user is just signing messages with something like an Ethereum address, it does not cost any money. If a user wants a human rememberable name on a chain, the only way to achieve this is by broadcasting a transaction. There are other layer chains that settle on Ethereum are very inexpensive at this point, with transactions often being less than $0.01. (Arbitrum Nova, Polygon ZK-EVM, etc) Ethereum currently is rolling out support for account abstractions on different chains, which allows services to cover these really low fees for their users if they desire.

Also, to register an account on the blockchain so that it is portable across lemmy servers (I'm assuming this data would just be like a public key or something for identity, not constantly registering things to the blockchain), doesn't that require money that users would have to pay for? No matter how low the fees are, that's going to be a much higher barrier to entry in comparison because users would have to create an account using a provider... blockchain auth might be useful as a recovery option or something, but I'm not sure exactly sure how it would be a significantly better solution than the proposal outlined in this issue.

I think the options available by using a blockchain are going to just going to work better than attempting to create the same thing without using a blockchain. They're really good for identity systems, and providing evidence that something did happen. It doesn't need to be that everything is made available on chain, but just that enough evidence is provided to a chain that someone can be confident that something did happen at a certain time in the past. (and can construct a full proof using data available outside of the chain) There's already lots of work done to do similar stuff, but I do think using a blockchain is probably a good solution if the goal is censorship resistance.

[0xAnansi]

This sounds like PGP with extra steps tbh.

[ghost]

I strongly disagree.

With PGP there are certificate authorities that provide trust to a domain. The domain then signs keys for email addresses. Identities are then distributed to key servers. It's not clear where to find anything. It also just completely failed, with most email providers never issuing keys for their clients. Over 20 years later, there is still not a way to send encrypted emails to specific users of a domain.

A NFT domain provides not only contractual control, but key pairs that have human readable names. They're also backed by networks that currently control billions of dollars.

[0xAnansi]

Unless I've missed something along the way, the domain will still be issued by a 3rd party registrar that you need to trust. This is how domain delegation works on the internet.

Using this, you can provide proof of ownership using a TXT record, or anything else related, and provide keys this way too, or link to anything since you control your DNS records.

I don't see how NFT changes anything, it just put a layer between the registrar and you for some reason, does it not? If the registrar is compromised (see the current issue with .ml domains), your NFT will be worth nothing.

On the broader subject, PGP is broadly used to sign packages for software distribution for decades. The fact that it doesn't work with e-mails has more to do with e-mails not being made to be encrypted by design that with PGP, and I say that even with all my hate about PGP and its issues.

[ghost]

Unless I've missed something along the way, the domain will still be issued by a 3rd party registrar that you need to trust. This is how domain delegation works on the internet.

Yes, you've missed something. The registrar does not exist. It's a contract.

[0xAnansi]

It might be a contract but for your browser to resolve the DNS entry for the domain to an IP, it's still linked to a registrar that has authority over the delegation of domains under a specific TLD.

[ghost]

This is incorrect.

The resolution depends on data that can be cryptographically verified on the blockchains of choice.

[ghost]

I quickly created a sample contract so that you can understand how this works. The main function that shows how this all goes together is runStorySample. I've added the function and the output as a image here.

The contract can be tested with Remix. It provides methods to query the example contracts.

[0xAnansi]

Can you quickly explain how your web browser will be made aware of the link between your domain and the server's IP if it does not use any DNS controlled by a 3rd party, usually populated by a registrar, since web browsers cannot query any blockchain directly?

From what I can gather, your contract is business logic to register a domain to a TLD owner with extra steps.

[ghost]

How do you verify that someone owns Bitcoins? You check the blockchain

[0xAnansi]

Yes, because I don't need my browser to resolve a bitcoin wallet's address to be able to use a service, which is not the case with domain name resolution.

[ghost]

If you wanted, you could mandate that all "RPC" resolvers must lock $100,000 in a contract that has a 30 day withdraw period after calling the function to withdraw. Then, on the client side, reject any resolutions that aren't signed with their relevant signatures. Then, if there's ever a problem with a resolution, you just use their bad signature to seize their funds on chain. (because resolution is done on chain)

The point is that resolution happens on chain. Verifying the resolution is as simple as verifying that you have the correct block data for the blockchain. (with Ethereum currently successfully securing billions of dollars)

From what I can gather, your contract is business logic to register a domain to a TLD owner with extra steps.

This also is untrue. There is no TLD owner for most blockchain domains. I just wrote a fast example.

[0xAnansi]

That still does not answer how you're not reliant on a registrar.

Today I own jlai.lu because I'm in a contractual relationship with a registrar. I can prove ownership with information that I can myself publish through the way of DNS records, which is done pretty much everywhere with 3rd party services asking you to create random TXT entries to show that you control the domain.

My browser, or anything that needs to access a resource bound to domain uses DNS. The DNS entry corresponding to jlai.lu and redirecting you to my server is considered truthful because my registrar is trusted. My registrar owns everything under .lu because the right was contractually given to them by states and authorities managing TLDs distribution.

If however my registrar becomes malicious, I'm fucked, because I technical do not own my domain. It's "rented".

Your blockchain based domain is the same except your registrar told you that it was secure because "blockchain" but in the end it's still a trust relationship, in the sense that if they decide to fuck up your domain, they still can because they own the TLD your domain is under.

The resolution cannot happen in the blockchain because domain name resolvers are not blockchain aware. Even if some are, the public do not use these resolvers and will therefore never get any positive response from public DNS. This is why I'm asking if we're talking about the same thing because it seems asinine to consider that domain name resolution can be done with blockchain.

The fact that ethereum is "securing" billions of dollar is still not an argument, no matter how much you repeat it. Central banks secure more, and that's what I use to pay for my domain. People still get scammed every day with fiat currency, as they do with crypto, no matter the underlying platform, ETH, BTC or whatever shitcoin of the day. It was shown enough that bad implementation is common and source of a lot of drama.

[ghost]

If however my registrar becomes malicious, I'm fucked, because I technical do not own my domain. It's "rented".

There is not a registrar. I'm going to stop now, you clearly are not trying to have a real discussion.

[0xAnansi]

you clearly are not trying to have a real discussion

bruh, I've asked you 3 times to explain how this is related to anything on a technical level, and at least one other person did too. I'm not the one peddling NFT and cryptobro things as technical answers to real life problems.

Lemmy domains are web domains, if you want to de-correlate the web domain to the whatever crypto domain, this is even worse because you cannot guarantee anything against domain squatting.

[ghost]

Lemmy domains are web domains, if you want to de-correlate the web domain to the whatever crypto domain, this is even worse because you cannot guarantee anything against domain squatting.

It's about censorship resistant multi-instance identities. The instances can register new names for their multi-instance names. No one questions why users use Outlook.com domains on Microsoft.com. It could be the same way but with .eth or other crypto registrars that meet the requirements.

[0xAnansi]

Who's returning an IP when you're resolving a domain with an .eth TLD ?

[ghost]

Who's returning an IP when you're requesting a domain with an .eth TLD ?

The blockchain.

[0xAnansi]

Please tell me how your browser is requesting the blockchain when you press enter on your keyboard after entering the domain in the "url" field.

[ghost]

Please tell me how your browser is requesting the blockchain when you press enter on your keyboard after entering the domain in the "url" field.

Usually, it's a resolution to what a user uses for their crypto wallet.

[0xAnansi]

No, explain to me what data is sent where, by whom, and what it returns, because unless some new DNS technology went live without me being aware, this is still not how domain name resolution happen.

[ghost]

I'm serious. If you're using Brave Browser or MetaMask, the resolution is done by the user's wallet. They also allow people to set their own RPC, but I doubt that is happening very frequently... There are domains that have survived cenorship already.

[0xAnansi]

So you need to use a specific browser and/or a specific extension to be able to override "normal" DNS behavior ?

[ghost]

I said at the start that MetaMask has 20,000,000 monthly active users and that Brave Browser has 50,000,000.

Resolution isn't even important here. The point is to tie blockchain based identities to user profiles so that they can be used across instances by the instance owners. Instance owners are going to be much more careful than users. I think they would be significantly more censorship resistant and versatile than relying on signature chains from certificate authorities.

[0xAnansi]

I said at the start that MetaMask has 20,000,000 monthly active users and that Brave Browser has 50,000,000.

So nothing as far as internet is considered.

Resolution isn't even important here.

Ok so why are we talking about domains from the beginning then?

The point is to tie blockchain based identities to user profiles so that they can be used across instances by the instance owners.

Are we talking user level identities or instance level identities? If you put an instance owner as the responsible for the keys of users, that doesn't solve anything. If users cannot manage their keys independently, that doesn't solve much.

Instance owners are going to be much more careful than users.

Seems like a dangerous assumption. This should not even matter for a trustless architecture.

I think they would be significantly more censorship resistant and versatile than relying on signature chains from certificate authorities.

It's mitigating one risk, this risk being a CA turning malicious but this brings a lot more new attack vectors, like shitty contract logic which plagues ETH for example, loss of wallet keys, malicious browser add-ons targeting metamask, etc..

PGP tries to solve the first issue by having separate keyrings that you can compare to see if the key is the same, hence my initial comment of this being PGP with extra steps.

If you want to combat censorship, just register your domain in as much TLDs as you can, just like torrent sites do. That won't protect against your assets being seized tho, but neither will the blockchain. I still don't see how the blockchain will help in any way that currently existing solution do not already do.

[ghost]

Ok so why are we talking about domains from the beginning then?

They're being used by millions of users as an identity system in the same way emails have been used. They have associated keypairs. They solve name to domain problems. They solve the registration problem for users. (Users currently would need a signature in the chain of trust from a certificate authority. The services could sign fake keys to existing users. This solves that problem by providing a auditable method for identity issuance)

Are we talking user level identities or instance level identities?

User, but there's not a reason instance level identities couldn't be improved with it too.

Seems like a dangerous assumption. This should not even matter for a trustless architecture.

They only have to make the mistake once for them to not make it again.

It's mitigating one risk, this risk being a CA turning malicious but this brings a lot more new attack vectors, like shitty contract logic which plagues ETH for example, loss of wallet keys, malicious browser add-ons targeting metamask, etc..

It's a method for social consensus on identity verification. The problem mostly being solved is server instances signing fake keys for existing users. This provides a way for all servers to issue their own identities and to be confident that the server is not stealing any assigned identity away from an existing user of their service. It's important to write good software, but it's just social consensus on identity. If it's no longer accurate then it's time to change it again.

PGP tries to solve the first issue by having separate keyrings that you can compare to see if the key is the same, hence my initial comment of this being PGP with extra steps.

One of many reasons this is better than PGP is because the identity issuer cannot steal their user's identity away from them just by signing a new key pair to the existing username

---

I'm just reading through this thread again, and I feel like I went off in just a different direction from the starting place of the issue. The goal proposed seems to be track when users keys change, which could be used to provide warnings and possible recovery on other instances from the changes. I think the solution proposed is easier to execute, as it does not require much involvement from the people hosting instances.

The stuff I was considering is probably better for a custom instance or something that implements ActivityPub itself. I still what I was thinking about is really good for identity systems, but I just don't feel like it's very relevant to the original discussion. Maybe instances as a whole could support blockchain based names too as just something optional for users to use?

[cogabe]

You failed to reply: how do my browser resolves "lemmy.eth" so that I can browse it? Do I tell the whole world to install Brave otherwise it doesn't work? This is not a realistic solution, I use Brave myself and .eth domains aren't even resolved. I don't know what I have to turn on, I don't care, it doesn't work, your solution doesn't work.

The blockchain doesn't do anything other than storing information. A relay will convert that into an IP. When you use Metamask, a relay replies for you, you are not running your own node, someone else gets your IP address in exchange for a domain's IP address. Call it whatever you want, your own solution doesn't work, just stop.

No, when I use Metamask, I don't access "the blockchain", I use someone else's server to access the blockchain for me. No, when I use Brave, I use someone else's server to access the blockchain for me.

Your solution doesn't work, you should stop wasting people's time.

[ghost]

how do my browser resolves "lemmy.eth" so that I can browse it? Do I tell the whole world to install Brave otherwise it doesn't work? This is not a realistic solution, I use Brave myself and .eth domains aren't even resolved. I don't know what I have to turn on, I don't care, it doesn't work, your solution doesn't work.

I think we're just off on another topic with not enough open mindedness at this point. I also think the original change in discussion is really not as relevant to the person who opened the issue. They were trying to solve a problem with instance hosters taking over their user's accounts, and their solution would provide a meaningful warning and recovery options to other instances in the event of an account takeover.

how do my browser resolves "lemmy.eth" so that I can browse it?

This question is purposefully trying to elicit a response that has not functionally been a problem. Blockchain based domains are better for the user if the user does not have to pay for them, and the implementation of the domain remains open.

A normal resolution for users of blockchain based domains is to query their wallet for how to check records on the blockchain. Often, it's just an RPC call to their wallet maintainer. It doesn't have to be that, and user's could have better guarantees about data with the trust being backed by deposits on chain. What's stopping the maintainer of the wallet from having the user sign over everything on the next update?

Do I tell the whole world to install Brave otherwise it doesn't work?

There are gateways. I think these domains are at a level of usage to where it is becoming notable.

Your solution doesn't work, you should stop wasting people's time.

If it doesn't work then why is anything worth money on chains?

[cogabe]

If it doesn't work then why is anything worth money on chains?

For example, if I want to register https://app.ens.domains/testlemmy.eth/register then I pay 5$ to ENS, and a transaction fee. I have to trust that ENS will never get hacked and I have to make sure my seed phrase will never get hacked either. I have no legal help in case something goes wrong, in case I get impersonated etc. I am on my own with a technology.

This question is purposefully trying to elicit a response that has not functionally been a problem.

And you failed to answer, once again. You won't tell me how my browser resolves lemmy.eth, therefore it is not a viable alternative, and you shouldn't advertise it, it is offtopic. Unless it becomes viable, secure, robust and easy to use, I'm waiting for adoption, in the meantime, we can't use that for lemmy.

[ghost]

For example, if I want to register https://app.ens.domains/testlemmy.eth/register then I pay 5$ to ENS, and a transaction fee. I have to trust that ENS will never get hacked and I have to make sure my seed phrase will never get hacked either. I have no legal help in case something goes wrong, in case I get impersonated etc. I am on my own with a technology.

Just take a moment to read my responses. I think maybe we're both rushing to conclusions, but I have taken the time to read yours.

And you failed to answer, once again. You won't tell me how my browser resolves lemmy.eth, therefore it is not a viable alternative, and you shouldn't advertise it, it is offtopic. Unless it becomes viable, secure, robust and easy to use, I'm waiting for adoption, in the meantime, we can't use that for lemmy.

The discussion was for user identities. It specifically was for servers to be able to detect if users on other servers had their accounts taken over by the server hoster. This could solve that solution by not allowing it to happen in the first place, as if an account is taken over on the server, the user could just use it on another instance without interruption. I don't think it was as relevant to the concerns of the original poster, as moving all users to it would require minimal effort by server instance operators. Though, users could still benefit with an optional integration where users handle the complexity of using a blockchain based domain with an instance.

[zyansheep]

This question is purposefully trying to elicit a response that has not functionally been a problem. (@fLgI6FeL02hKr2g4qBj0hEfN4VvA6TpN)

Off-topic, but this is kinda funny to me as users interfacing with blockchain has historically (and possibly still is?) the main issue with blockchains (users can't participate in the network, because they aren't on all the time and can't store the whole chain!)

how do my browser resolves "lemmy.eth" so that I can browse it? (@cogabe)

I believe it is as you suspect, you need a special browser that either uses a dedicated centralized resolver or some kind of p2p IPFS/Ethereum thing. Or, alternatively, a browser extension that does something similar.

Overall, I think integrating blockchain-managed identities into lemmy might be a good idea long term, but given that most of the technology is incredibly new and not really known to most of the internet (or even most developers) there is naturally going to be suspicion as to whether or not it will work. (Cryptocurrencies in general, including ethereum are basically pump-and-dump schemes, so who knows what might happen! Also: repeatedly saying that it secures billions of dollars as a justification of its security is probably not going to convince people of how worthy it is to integrate into lemmy). Perhaps once the technology matures (or out-competes?) us, it might be good to look into really integrating blockchain tech into lemmy, but for now I think it adds more unneeded complexity, and unnecessarily relies on various uncontrollable factors such as:

• The health of the currency and validators
• The reliability of 3rd party chain resolvers (or newly created P2P networks)
• The reliability of developers not screwing up smart contracts :eyes:

I hope my observations are reasonable, but if you have any objections, could we move the conversation to a separate issue? You've kind of hijacked this one lol.

[ghost]

Off-topic, but this is kinda funny to me as users interfacing with blockchain has historically (and possibly still is?) the main issue with blockchains (users can't participate in the network, because they aren't on all the time and can't store the whole chain!)

My opinion is that if users can correctly and confidently resolve balances, they can correctly and confidently resolve domains too. They're functionally the same.

I believe it is as you suspect, you need a special browser that either uses a dedicated centralized resolver or some kind of p2p IPFS/Ethereum thing. Or, alternatively, a browser extension that does something similar.

It's just checking a record on Ethereum's blockchain to determine the state of the contract. The contracts actually allow resolution based on user defined contracts. In the example I provided, a user could just provide a new implementation for the resolve function and it would work with the registrar's domains. Though, there are two types of resolution, who has ownership of the NFT, and where domain resolves for a specific record. The changes to make something like this work can be seen in this gist.

Implementations like this provide powerful options for decentralized organization control of their shared account on a platform.

but for now I think it adds more unneeded complexity, and unnecessarily relies on various uncontrollable factors such as:

When I originally responded and linked to this thread, I also created issue #3682. My thought process at the time was that a more general sign in process should be created for other services connecting together, with like "sign in with MetaMask" being one of the options for authenticating. I think it provides a much stronger guarantee for accuracy of identites for the users that use them compared to any other proposed solutions here.

I don't think I originally intended to push for all users to have blockcahin issued accounts, but my comments read that way more so to me when I was rereading it.

[maxpoulin64]

All of this would require extensive changes to how Lemmy works, and would also require major changes to the ActivityPub protocol. The protocol inherently puts a lot of trust in the owner of each instance, and a lot of things are straight up identified by an URL. A person for example has an ID of https://instance.example/u/ExampleUser, so implementing account portability is not really possible within the confined of ActivityPub.

I believe what you're looking for is Aether. It implements a lot of what's been discussed in this thread, including Scuttlebutt and blockchain identities.

Lemmy just wants to be part of the Fediverse, and all of those changes would make it incompatible with Mastodon/Pixelfed/Firefish/Friendica and others. None of this is also very user friendly, although robust and secure and private.

[ghost]

It looks like an interesting platform, but, requires a native application to access a website. I'm also doubtful it has access to as many users as a service that tries to be a part of the fediverse.

I think there are reasonable ways to integrate existing blockchain domains for instances. As an example, if instances currently depend on certificate authorities, then a gateway could be created like existing gateways. The instance would function mostly completely normally, but have custom management for the registration of users so they could use their exisitng names from their registrars.

As an example, with

• _user_domain.blockchainTLD.gatewayinstance.TLD

A user could have a compataible fediverse username assigned on the instance that is

• user_domain@_blockchainTLD.gatewayinstance.TLD

Then these types of instances could just seemlessly provide the username for blockchainTLD's, and other people could easily create their own instances. Wtih all of this said, it seems like custom development will need to be done, and it might just be better for this type of development to be done completely independently of Lemmy. (or just try to follow changes with a different account registration system)

I think the relevance is that if there are Sign-In Providers, there could be multi-instance IDs that issue fediverse usernames based on the provider the user used. As an example, a user joining with a Google provider could be issued

• user@_google.instancename.TLD

Then all instances could all issue the same username for that user when they use that provider.

Something like this could create mutli-instance censorship resistant identities, but the censorship resistance is only active when users are using a provider that supports it.

[WayneSheppard]

@fLgI6FeL02hKr2g4qBj0hEfN4VvA6TpN I'm all for portable users. My home Lemmy instance just disappeared one day without any warning. Two things:

Are there any other real websites out there using what you are describing? I'd like to see how this behaves in the real world. Or is this all just theory?

Shouldn't this change be at the ActivityPub level, so the entire Fedeverse can take advantage of it? Adding it just to Lemmy would break Mastidon and other federated services. https://github.com/w3c/activitypub

[ghost]

Are there any other real websites out there using what you are describing? I'd like to see how this behaves in the real world. Or is this all just theory?

Yes.

DXdao uses it for their contracts and primary website. The link below obviously only resolves for people using Brave Browser or a browser with MetaMask.

• https://dxdao.eth

Before Tornado Cash's legal entity was broken apart by sanctions, they had a domain being contractually controlled as a method for accessing their frontend

• https://tornadocash.eth

After the sanctions, they then continued updating their ENS domain by DAO votes.

Proposal #14, Contract that executed on vote pass that updated the ENS content hash

The DAO then suffered a hack, and I do not know if the DAO still maintains control of it.

Vitalik Buterin also uses an Ethereum Name Service domain

• https://vitalik.eth

I have previously been interested by it too, and in the past have completed a single resolution of all ENS domains that had content set. I only attempted to resolve the records with a single pass by using Infura, so there are some domain content hashes missing. One benefit of domains being on the blockchain is that anyone can rapidly build a database of the domains that resolve.

• Ethereum Name Service domains with a set content hash. This list was created in March of 2023.

This dashboard tracks usage of Ethereum Name Service domains. There are other blockchain based domains though, but I've watched Ethereum Name Service domains more. Also, like I previously stated, there are over 2 million registrations of Ethereum Name Service domains, with the domains having a total volume of 87,000 ETH on OpenSea.

Shouldn't this change be at the ActivityPub level, so the entire Fedeverse can take advantage of it? Adding it just to Lemmy would break Mastidon and other federated services. https://github.com/w3c/activitypub

I haven't made an effort to understand W3C's governance yet. I don't think it would break them, just make them not as feature complete.

I think trying to have these changes done at the ActivityPub level would take more effort than just starting changes here and then trying to also have them done at that level. They're not ActivityPub breaking changes. Though, their governance might want to make decisions or change how it is implemented.

It does seem like this issue was created to solve Censorship-Resistant Multi-Instance Identities on Lemmy instances though

[WayneSheppard]

So I checked to see what it would take to register an ETH name. Apparently this costs 2 ETH for 1 year. That's about $1,800 converted to USD. IMO, any solution that is not free is a nonstarter.

[ghost]

Registration of ENS domains are more expensive than other domains because the gas fees on Ethereum are high. The other chains use Ethereum, and post proofs back to the main chain. There's many people who want their transactions and cryptocurrencies on the first layer of Ethereum because of the security guarantees, etc

• The registration cost for a 5 character ENS domain is $5.
• 4 character domains have a fee of $160
• 3 character domains have a $640 fee

The gas fee at the moment is about $15, so the total is about $20.

---

There are other providers. As an example, I think space.id aggregates ENS-like registrars on two other chains. These should have nearly free gas costs. ($5 actual total~)

I don't really want to convince someone that they should purchase and use one of these types of domains. Though, I previously explained that chain fees on other networks like Polygon's ZK-EVM or Arbitrum Nova are very low, (less than $0.01/transaction) so there are options that could be made available for basically no cost. (The cost being associated with just keeping people from registering names on speculation that specific names will have high resell value)

I think for a small percentage of people, it might actually make sense for them to purchase a blockchain based domain from a well known registrar. Then, following that, I think there's actually a lot of use for domains in general being available on blockchains, but not that they need to be decentralized domains. (They could use their domain as collateral for a loan, use it for social media, etc)

I think most people are registering them for reasons that are unrelated to the functionality provided from a blockchain based domain. (Usages include to receive and send funds, easily show what they have collected on chains, make sure people sending are using the correct address, speculation, etc)

Anyone can create a registrar. The cost to deploy a contract is very low on other chains. The source code of a specific contract will have the same functionality, even if it is deployed by someone else. The cost could be really low for a custom TLD. Though, if everyone is creating TLDs, then domains become confusing again. The better solution would to limit blockchain TLDs, and register more so free domains on subdomains like normal domains have functioned.

[zyansheep]

Shouldn't this change be at the ActivityPub level, so the entire Fedeverse can take advantage of it? Adding it just to Lemmy would break Mastidon and other federated services. https://github.com/w3c/activitypub

Changing specs is slow and writing specs is hard! especially when you can't easily test reference implementations... The last update to the ActivityPub repo seems to be 4 years ago, but even if it was feasible to contribute a specification, it would be hard to test it in practice on a real social network... Because of that issue, I think It'd be better to create a proof-of-concept activitypub compatible implementation on Lemmy, refine that implementation to be effective and scalable, and then once the users have tried it and people like it, it could be eventually upstreamed into activitypub.

[basxto]

For most users this would probably just be annoying, I suspect that still a lot of laptop/desktop users will use web-UIs. Those then need to enter two passwords, one for their account and one for signing. The latter probably would need to be entered every time a new browser session starts and a malicious instance could easily modify the UI in a way to steal private keys when they get entered. That’s also why PGP doesn’t work well with web clients for mail. Installing separate client programs or special browser addons isn’t a step everybody will take, but it becomes nearly useless if that step isn’t taken.

[Nutomic]

This is way too complex and out of scope for Lemmy.