Hacker News Reader

This is basically the entire point of the Authenticated Transfer Protocol (AT Protocol), which powers Bluesky. I think it does a ton of stuff right, including portable identity backed by solid cryptography (no blockchain or "crypto"!) and has a lot of promise. It's still in development, but I am hopeful that it will live up to its promise.

can't a malicious bluesky admin steal/MITM users' private keys by messing with whatever frontend javascript users interact with?

Yes, at the end of the day a malicious client is always a risk with this sort of thing. But the AT Proto does have some mitigation in place—users have a signing key which their PDS needs to act on their behalf (sign posts, etc) and a separate recovery key which users can hold fully self-sovereign and use to transfer their identity in case they detect malicious behavior. It's not foolproof of course, nothing is, but it is thoughtfully designed.

But yes, the protocol does have a fair bit of trust of your PDS built in. But that's inevitable for decent UX—imo the crypto craze proved that basically no one wants to (or can) hold their own keys day-to-day. If you want to have a cryptographic protocol that the average person can use, some amount of trust is necessary. The AT Protocol artfully threads the needle and finds a good compromise that is a (large) improvement over the status quo, in my opinion.

In theory, kinda, but you can bring-your-own client, and "the" web client is decoupled from the back-end instance.

"bsky.app" works as a web client for the official "bsky.social" instance, but it also works with the instance I self-host (or any other spec-compliant instance). Likewise, 3rd party clients work with the official instance, and also with 3rd party instances.

However, no key-stealing could possibly happen right now in any case because... the PDS ("instance") holds your signing key - the client never even sees it. Having the server hold your signing keys is very user-friendly, but of course not ideal for security and identity self-sovereignty. In general, the security model involves trusting your PDS (just as you trust your mastodon instance admin, or twitter dot com - the improvements are centered around making it easier to jump ship if you change your mind).

Client-signed posting is something that's not even possible right now, but I believe it's somewhere on the roadmap. If it doesn't happen some time soon I'll be implementing it myself. (I'm writing my own PDS software)

How is this better than everyone having their own Wordpress or Drupal install?

That's never going to work for the average person, sadly. And it misses a lot of social features that a lot of people (myself included) want from social media. Simply put, the UX is way too far off what people want and need.

It will, ISPs just need to start providing the basic hosting infrastructure on their routers again, like they used to. Thankfully we're also at a time where IPv6 is mature enough so that this is greatly simplified !

Wordpress doesn't have ActivityPub built in, it's a plugin in beta currently. Without AP, there is no client that can pull in website feeds and provide discoverability between WordPress sites, Mastodon posts, etc.

Back in the old days, activitypub was my Rss feed reader. Discoverability was driven by good old fashioned cross linking, comment discussions, and skimmable feeds from aggregators like the one we're on.

People love to reinvent the wheel and claim it's a whole new thing. No ideas on the web have really been innovative since the bubble popped. The innovation has all been on delivery and execution (not wanting to discount any of that).

WordPress is not exactly known for its security.

Sure it is? WordPress updates itself and all plugins automatically. I've had Wordpress sites running for over a decade with zero security concerns ever popping up.

Maybe your point of view is outdated?

> For me the main barrier is that I want to have portable/roaming control over my IDENTITY, even if the content hosting is (for now) entirely through a system administered by someone else. If I control the identity, I can at least keep local copies and rehost/repost content later.

This is why I want domains as identities to succeed. I want to own my handle on every platform, but I don’t want to self host.

Do you know of any existing projects in this space?

I was toying with an idea/protocol where:

1. You add a TXT/CNAME that points to a trusted "authentication provider".

2. When you try and login to a website that supports the protocol, it checks the DNS record and redirects you to your provider.

3. You then "prove" that you own the domain to the provider - how this is done would be specific to each provider, but one possible method could be by providing a signed message that can be verified vs. a public key stored in a DNS record.

4. The provider redirects you back to the original website with a token.

5. Finally the original website consumes this token by sending it in a request to the provider. The response contains the domain as confirmation of the user's identity.

This approach removes the need for self-hosting as users can point and setup their names with third party providers.

Users can also trivially switch to a different/self-hosted provider by changing the CNAME.

Communities could also allow direct registration by hosting their own provider instance and pointing a wildcard subdomain at it: (i.e. *.users.ycombinator.com).

Users could then sign up to said provider using traditional email/password and claim a single subdomain: (i.e. tlonny.users.ycombinator.com)

Thoughts?

GP wants not to self host yet wants to have the control.

Though what you described is just a regular federated identity workflow, except autodiscovery through DNS (though that is already a thing for some)

So where is it kept then?

Sounds they want self custody of their keys. This isn't what the general public want.

Decoupling identity from social is a good idea but you can't just migrate the key storage to a single custodian entity. There'd need to be a multiple custodians to ensure the same power imbalances didn't reappear in a different form (e.g. Google owning everyone's logins).

Exactly. There is no magic trustable non-local/distributed system that replaces 'self-hosted' for this purpose.

All that is needed is a to create your local identity (e.g. like storing fingerprint biometrics on your laptop) and a clever way to sync between physical devices (e.g. through bluetooth).

We're in this weird situation where people don't want to be responsible for managing their own data/id, but can't trust others to do so for them.

I raised issues on mastodon and plemora advancing this view a few years back, to an initially frosty reception that’s since become a grudging “nice to have but hard to add”.

My recommendation was much like MX records for email, so you can use a hosted server under your own identity.

There are people who want to add distributed identity to ActivityPub. It was left out of the spec but there were things left in to make it possible to add later. That's my understanding from a distance, anyway.

I've been able to switch mastadon instances without any problems; most instances seem to handle whatever activitypub machinery transfers followers.

So as long as both your source and destination support account transfers, you can usually switch and even seamlessly bring along most of your followers without them noticing.

No idea about your admin question. All bets are likely off with a bad admin. If you want actual cryptographically guaranteed communication, that doesn't exist in a usable form (except for Secure Scuttlebutt, and that's reeeeally stretching the "usable" part)

> I've been able to switch mastadon instances without any problems; most instances seem to handle whatever activitypub machinery transfers followers.

But none of your content goes with, and that's really terrible because it gives a lot of power to petty-kingdom jackass admins.

AT Protocol is heartening because maybe they've got a good solution to that.

You can export your content on the old insurance and import on the new instance

That doesn't actually work, though. Old links don't update or forward to matching instances of your toots on Mastodon. They're isolated. It's a bad experience.

That's a good point. It would be nice to have a streamlined export flow that rewrites your links for you.

(It's technically possible to edit the links in the posts you exported yourself before importing, but technically correct isn't the best kind of "correct")

If your instance suddenly dies without prior notice, you won't be able to transfer your account.

Keep an eye on Key Event Receipt Infrastructure (KERI). https://keri.one/

Current spec drafts at <https://github.com/WebOfTrust/keri>.

Didn’t the guy who founded the web basically make something like that?

Yes, Tim-Berners Lee led the Solid project[1], which reverses the client/server identity and data model. The user will store their own data and the service provider can only access it under the policy set by the user.

The promise is that one can not only transfer the identity and all personal data across instances of a single service, but also across different services (imagine from mastodon to Lemmy).

Sadly, it never caught on.

[1]: https://solidproject.org/

Firstly, agreed totally about identity.

Secondly, signing every message wouldn’t be impractical at all, I don’t think. We’ve had the technology to do this for a long time and it’s very simple. What we don’t have is good key management. For average users, this would have to be something provided by their devices (phone or the Secure Enclave in your Mac or whatever) - managing keys and the web-of-trust shamozzle are the main reasons why encrypted email for everyone never took off.

It’s being worked on:

https://aumetra.xyz/posts/fediverse-nomadic-identities

https://aumetra.xyz/posts/nomad-id-first-steps

Fediverse identity is based wholly on URL. If you want to own an identity, you own a domain.

This sounds like you want to self host, then federate with instances?

Not OP but I want to point my dns at a host and have them handle it.

You can pay for that service, but you have to administer the instance, and it’s not able to reuse the servers RAM for multiple domains; it’s not like email where spam management is built in.

I'm not too clued in with how federation works - but is this practical?

Doesn't federation require admins of both instances to agree to federate?

If so, I could imagine it not scaling for larger instances that could receive 100+ federation requests a day.

Further, you would have to repeat this step each time to encountered a new instance you wished to participate on.

Is my understanding of the federation process correct or have I totally missed the mark? :D

The federation is opt-out, so by default an instance will accept any federation request. You only block bad instances after the fact (or use some kind of shared blocklist)