How to set your domain as your handle | Hacker News Reader

How to set your domain as your handle

blueskyweb.xyz

181 pointscarride152 comments

What the AT protocol got right is that your handle is also a url. Because it is a hostname.

I always thought ActivityPub should have used hostname/username instead of @username@hostname for the handle. Then they would have that advantage too. And one less char in the handle.

What I find a bit cumbersome with the AT protocol is that it uses DNS records to store the metadata of an identity. I wonder if it should have used a simple json file instead. So that the protocol would not look at the DNS records of a hostname for the metadata but at hostname/at_identity.json

That woule make it much easier for owners of a hostname to use it as their AT identity. Building tooling around the AT protocol would also get easier.

How is running a web server for a JSON file easier than creating a TXT record in your DNS?

Then when you want to use the AT protocol without a webserver, you would have to set a DNS entry (CNAME) that points to a service like Bluesky. So for users without a web server, it would stay the same amount of work.

And for others it would be just

echo 'my metadata' | ssh myhost "cat > /my/web/dir/at_identity.json"

> And for others it would be just

+ hosting the server + admin the server + securing the server + keeping the server up all the time

For trivially small amounts of data it seems a massive waste of time and effort.

If however, you are storing and verifying identity of 100's+++ of users within said domain then hosting that makes sense (pgp for email should probably work this way).

But why

Nevertheless, they’ve added this a couple days ago. Someone has already created an S3 bucket called “xrpc” and is using s3.amazonaws.com as their handle. :)

—— From @emily.bsky.team:

you can also use a non-DNS option — serve some JSON at a well-known endpoint (similar to webfinger)

  GET https://<users-handle>/xrpc/com.atproto.identity.resolveHandle
  {"did":"<users-did>"}

atproto handle resolution tries DNS TXT first, then will try an HTTP endpoint. the endpoint is not a ".well-known", it is an "/xrpc/"-prefixed endpoint with a query parameter, which is workable on some static hosts (like github pages), but not others.

not well documented yet. may try to do a ".well-known", but don't want a sprawling set of options with complex priority levels and caching behaviors.

At this point not just using webfinger just feels contrarian for the sake of it.

But then again so does a whole lot of Bluesky. That is, a whole lot of Bluesky could have been designed to interoperate with the fediverse without sacrificing functionality. The choice to instead privately design something entirely different to me speaks strongly to an attitude to openness and community building that makes it a non-starter for me.

I kind of like that they're tying it to DNS, which is probably the most successful decentralized system to date.

Fediverse doesn't really seem to scale at the individual server level, which is a sort of weird UX.

Creating a domain name is both cheaper and easier than running your own fediverse server.

Webfinger is entirely separate from ActivityPub, and is already used by other things like e.g. RemoteStorage.

Even if we postulate that what you say is true (I don't agree it doesn't scale, and there are increasingly commercial offerings if you don't want to run your own and there will be more, but let's put that aside), none of that stops people from using webfinger. If you want more than one user on the domain, it requires at a minimum the ability to dynamically rewrite a URL to redirect to a static URL (or you can of course have a fully dynamic endpoint), otherwise it just requires the ability to serve up a single static file.

While I kind of like using DNS myself, and might have gone that way if starting from scratch without an alternative existing, the existence of webfinger and the fact it is in use for multiple things would have made me stop and think twice and just use webfinger.

To late to edit here, but an additional thought: If Bluesky starts getting traction, a move to undercut it from Fediverse proponents would be embrace and extend: Augment clients with webfinger, provide bridging to the Fediverse, and generally aim to make Bluesky users expect to be a part of the wider Fediverse. Only if Bluesky very rapidly overtakes Mastodon to the point of dwarfing it or remain an irrlevance, will it have a realistic prospect of remaining what they want it to be rather than turn into some hybrid that runs away from them.

Webfinger needs to be updated or replaced anyhow - it wasn’t specified in a static file hosting compatible way and expects a dynamic response or custom server rules. Not that bluesky helps here either.

It's easy to do. Here are some examples: https://www.packetizer.com/ws/webfinger/server.html

I actually serve up content using both static files and via dynamically generated content, depending on the domain and needs.

Those are steps for running a server with rules engine. I don’t want a server, I want users to be able to access a CDN directly which may not have such flexible rewrite rules. I’m building a kind of bluesky alt that works entirely statically and should be flexible to file hosting

Nice! So the file approach does work. Do you have a link to the documentation of the file approach?

Why does the DNS approach exist at all? Couldn't users who own a hostname but have not connected it to a webserver have achieved the same by adding a CNAME to a service like Bluesky?

I don't really understand your question.

Maybe it helps to clarify that the concept of a handle is totally distinct from the "Personal Data Server" or PDS. You look up the PDS for a handle by resolving the DID first (via DNS TXT or HTTP fallback), then get a DID document, which has a URL to the PDS. This is a bit confusing and multiple steps, but is what makes the handles so easy to use. It is totally fine to have a cool domain to use as a handle and just not have a webserver associated with it.

If you pointed the domain with a CNAME to a particular service, you would need to update that every time you change hosting providers. Which is maybe not often, but it would be disruptive and potentially poor experience because of DNS propagation issues.

For a hypothetical brand like google.com, look up the TXT records. There are a bunch of verifications for various services. This is a relatively standard mechanism. TTL and caching are built-in to DNS, or you can punch through with a recursive query when needed.

The challenges around changing hosting providers are the same for websites, aren't they? It seems to me they are well understood these days. I don't hear many people having a pain point around it anymore. A short TTL usually is enough to avoid a lot of DNS caching issues.

And wouldn't changing the name server have the same effect on the DNS solution? "Every time you change your name server provider ...". Which for many users is the same as their hosting provider.

Do I assume correctly, that you don't link to the HTTP fallback documentation because you don't want people to use it?

Activitypub identities are URLs, nothing more. https://social.example.com/pickleman is an activitypub identity.

Some people layered webfinger mentions on top of that, but the protocol neither uses nor depends on it.

Unfortunately not. Activitypub Identities are @username@hostname.

When you have one of these and want to find the user, you have to ask hostname at ...

    https://{hostname}/.well-known/webfinger?resource={...}

... for more infos about the user. {...} being an urlencoded version of "acct:{user}@{hostname}".

Then you will get a bunch of stuff, including so called "aliases". Which are urls. Many services provide aliases of the form hostname/@username or hostname/users/username. Which are endpoints that display something about the user. But that is not part of the protocol and differs from service to service.

Totally backwards. The AP identity is whatever url endpoint you want it to be. People use webfinger to turn @handles into that url, but you can also just use the url directly. Grab the actor, find the inbox, send your post.

That is not how I read the specs. Let's look at an example:

My handle is @mg@masto.ai

What is my "AP identity" in your interpretation of the AP protocol?

You're thinking of Mastodon. There's no mention of using @ in identities at all in the ActivityPub spec: https://www.w3.org/TR/activitypub/#actor-objects

Usernames can be represented as whatever, but they're not the user IDs.

Peertube implements ActivityPub and uses username@server instead of @username@server, and so does Pixelfed. Funkwhale uses https://hostname.tld/federation/actors/Alice as their ActivityPub identifier (they support multiple federation protocols) and doesn't have a clear representation of user + domain as far as I can tell.

There is no mention of "identities" or "identity" in the spec either.

So if a person is available via ActivityPub, how do they reference their "identity"? When you want to say "Follow me via ActivityPub: ..." - what is "..."? The most common form I see is @username@hostname. Is there a more universal form? How does a Pixelfed user do it?

The most common form is @username@hostname, sure, because it's convenient, and also because doing a webfinger lookup of that is more generic - a webfinger response can include far more than AcrivityPub endpoints.

But specifically for ActivityPub the URL works just fine (try pasting it in the Mastodon search box, for example, and up pops the user details exactly as if you'd used @user@host)

You say "the url works" as if there is a clearly defined url for every Fediverse user. But the way I read the specs, that is not the case.

Some servers link you to hostname/users/username, some use hostname/@username, some use hostname/username when you look up a user via webfinger.

And the way I read the specs, those don't have to be permanent. A server could change their scheme from hostname/users/username to hostname/u/username and would not violate the protocol. Because the way to identify the user is via a webfinger lookup.

Maybe the only way to say who you are on the Fediverse is "I am <username> on <hostname>. Look me up through Webfinger"?

That might be the equivalent of saying "I am https://masto.ai/.well-known/webfinger?resource=acct%3Amg%40..."

> You say "the url works" as if there is a clearly defined url for every Fediverse user. But the way I read the specs, that is not the case.

There is a clearly defined URL for every Fediverse user, but not in the sense you mean (there isn't a static or predictable mapping from user@host to URL). The Fediverse is a graph of Person actor urls, not @user@host ids. The Webfinger lookup functionality is used because it makes things more flexible for users and because webfinger allows for a single identity to refer to multiple different types of services and resources, but my followers servers and the servers of those I'm following knows me as https://m.galaxybound.com/users/vidar even though @vidar@galaxybound.com is what I use.

> And the way I read the specs, those don't have to be permanent. A server could change their scheme from hostname/users/username to hostname/u/username and would not violate the protocol. Because the way to identify the user is via a webfinger lookup.

See my other comment. A user is identified via a webfinger lookup when trying to determine which Person Actor @mg@masto.ai refers to. But in almost every other context the only thing that is stored is the URI of the Person actor. If that changes without using the (not in ActivityPub; new) move functionality, you're effectively creating a new identity, and quite a few servers do not yet support the move functionality, so while you can change @mg@masto.ai at a whim and nothing will break, changing the URL is what you need to be careful about (too careful, as I've noted elsewhere; the better support for migrating your data is pretty much the only thing I like about Bluesky)

Since more people are trying to prove you wrong, I’d argue it can’t be too late for Mastodon to fix that username scheme used in the frontend app. And agreed that double @ is stupid.

Mastodon supports URI's in the UI, and resolves @user@host names to profile URI's when you post as it is, so the use of webfinger is almost entirely a presentation/convenience issue anyway. I also dislike the double "@", but I get the thinking that starting "@" has to some extent become a signifier that what follows is a social handle.

It's https://masto.ai/users/mg. You can see it by running curl -H "Accept: application/ld+json".

https://www.w3.org/TR/activitypub/#obj-id

That is one of the aliases. The same holds true for ...

    https://masto.ai/users/mg
    https://masto.ai/@mg

... and the server could povide as many aliases as it wants to.

I wouldn't call those "identities". As the server could just change the aliases and the handle "@mg@masto.ai" would still work. Because it resolves to whatever aliases the server provides via the webfinger endpoint.

I have not seen anything in the specs that says the aliases are identities or should stay the same over time.

Try this:

    curl -H "Accept: application/json" https://masto.ai/users/mg/following?page=1 | jq .

Notice the people you are following are referenced by URL. If you try /followers instead, and look up the following URLs of some of your followers, you'll find that they follow you by the URL

    https://masto.ai/users/mg

If you do:

    curl -H "Accept: application/json" https://masto.ai/@mg | jq .id

You'll see that the returned document shows the id of your ActivityPub Person actor as https://masto.ai/users/mg, not https://masto.ai/@mg or @mg@masto.ai.

@mg@masto.ai can change and nothing will happen (even old mentions should still work, as at least Mastodon resolves the mentions to the Actor url and includes a mapping in the post). But if the https://masto.ai/users/mg URL changes, you will need to trigger a move, or you'll lose your followers, because from their servers point of view, that URL is your identity or in ActivityPub speak it's the identity of your Person Actor and for most purposes that's all ActivityPub cares about.

So while you can introduce aliases in webfinger, and for the purposes of webinger your id is mg@masto.ai, if the primary ID of the ActivityPub Person actor changes, you need a "movedTo" element to point to the new one, an "alsoKnownAs" to point to the old one, and trigger notifications to the servers of your followers and following for things not to break horribly. See e.g.:

    curl -H "Accept: application/json" https://mastodon.social/@vidarh | jq .movedTo

And

    curl -H "Accept: application/json" https://m.galaxybound.com/users/vidar | jq .alsoKnownAs

This is not in the ActivityPub spec - it was added as an extension as people started to want to be able to move more smoothly.

(I personally don't like this dependency on the old server in the move process, and so one of the few things I actually like about BlueSky is the ability for a user to take their data to a new server unilaterally; that could be fixed for the Fediverse without an entirely new protocol, however - it just needs a mechanism similar to the recovery key mechanism of BlueSky to let users prove who they are on a new server)

In effect, you have two identities in the Fediverse:

* You have a webfinger identity acct:mg@masto.ai

* You have an ActivityPub Person actor identity https://masto.ai/users/mg

Changing the former, or adding more of them (you can even just add a redirect on your own domain and user@yourowndomain will work and resolve to your https://masto.ai/users/mg identity; this is how my Mastodon is on m.galaxybound.com but my preferred Mastodon handle is @vidar@galaxybound.com without the "m."), is easy. Changing the latter is complex (more than it should be).

    curl -H "Accept: application/json" https://masto.ai/users/mg/following?page=1 | jq .
    Notice the people you are following are referenced by URL.

That we can see entries of the form hostname/users/username in the output of a that specific curl command is proof that it is the identity of a user as defined by the ActivityPub protocol?

Shouldn't we be able to look at the ActivityPub specs and see how the identity of a users is defined?

To quote the spec:

    'In ActivityPub, a user is represented by "actors" via the user's accounts on servers.'

and:

    'All Objects in [ActivityStreams] should have unique global identifiers. ActivityPub extends this requirement; all objects distributed by the ActivityPub protocol MUST have unique global identifiers, unless they are intentionally transient (short lived activities that are not intended to be able to be looked up, such as some kinds of chat messages or game notifications). These identifiers must fall into one of the following groups:

    1. Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs).

    2. An ID explicitly specified as the JSON null object, which implies an anonymous object (a part of its parent context)'

and:

    'All objects have the following properties:

    id
    The object's unique global identifier (unless the object is transient, in which case the id MAY be omitted).'

So a user is represented by an Actor, an Actor must have a global identifier, and that global identifier is the "id" field in the JSON. https://masto.ai/users/mg in your case.

(You may also search the ActivityPub spec for "webfinger"; it is not mentioned - it's a convenience offered by implementations like Mastodon, and not required by the ActivityPub spec at all; your interop with Mastodon will be harmed if you don't support it, but it'll work - users just need to input your url instead)

EDIT: to further underline the relationship of Webfinger to ActivityPub, look at the section for Actor's [1], and how the use of webfinger lookups violate the spec ("otherwise, the entered value should be considered invalid") - it's an extension/change used by things like Mastodon for user convenience, and not part of ActivityPub itself at all.

[1] https://w3c.github.io/activitypub/#actors

Awesome!

That's pretty cool. So the ID of an ActivityPub actor is simply a url.

That is great.

I think Mastodon should have made it so that the url for their users is hostname/username and that is their ID as well. That would have prevented a ton of confusion.

I think there'd have been confusion either way, with people expecting to put the URLs into a browser rather than a social app, especially as there's no uniform way of recognising that they're Fediverse-related without visiting the URL first, so I think having an indicator of that there is worth it, but e.g. the masto.ai/@mg style URL are a lot better than the masto.ai/users/mg.

The webfinger support also potentially enables some cool functionality by letting users use the same handle for multiple services. That said, I'd love to see someone set up a webfinger service that 1) lets people bring their own custom domains, 2) shows a linktree style UI if you hit host/username, 3) optionally redirects or transparently caches certain settings, 4) offer to transparently redirect requests to the user page a given resource based on Accept: header where possible (e.g. ActivityPub/ActivityStreams technically expect 'application/ld+json; profile="https://www.w3.org/ns/activitystreams" ' with the caveat that the "profile" bit is likely to be left out by a lot of clients)

If you have your domain pointed to a substack, you can still edit the DNS records, but you can't upload JSON files.

Simple and fundamental. I’m behind this.

I don’t fully understand how decentralized these alt-twitters are. But to the extent they can replicate the basic functionality while not requiring mega cap profits it might be a win for us all.

I hope it’s not just a fad.

I always try to distinguish between decentralization of infrastructure and decentralization of control. I think the former is very difficult to achieve, but that’s ok because the latter is by far the more important of the two.

As long as I can (technically) take my domain based handle and move to another host I’ll be thrilled. I also hope it’s not a fad because I think it’s a huge win for users, especially small businesses.

I wonder how they handle dropped domains that are re-registered.

dropped domains will be a bit of a UX problem.

the human root of identity is the handle (memorable/recognizable), but the real identity root for the account is a DID. which is a pretty open/wild spec, so we mostly use did:plc ("placeholder"), which is a self-authenticating tricky tricky.

withing the protocol and applications, everything under the hood works via DID references, not handle references. a domain handle works by pointing at a DID, but does not control the actual DID ("DID document"). so any old users/followers/href will still be attached to the "old account". and it would be possible for the old account to recovery and set up a new handle.

but the superficial bits (anchor text), and human identity for new lookups, are attached to the handle, and could get pointed to a new DID, or just not resolve. that would be messy.

I’ve been thinking about this a bit more. What happens if the server operator bans a DID? Does that ban the DID across the whole network via federation? What if I run my own server? Does that make me un-bannable?

Is there even such a thing as DID bans or is everything handled via moderation and filtering? I’m guessing impersonation would still be an issue even if domain based handles solve most of the impersonation problem.

So the domain is a mutable pointer to an immutable DID? That’s pretty much how I’d do it too [1]. Very cool!

1. https://news.ycombinator.com/item?id=32755618

They aren't decentralized, they're federated. If you are on an "instance" of an alt-twitter (e.g. mastodon.social) you are 100% subject to the rules of that instance and your handle isn't portable, though you can generally share content across instances and interact with others.

>you can generally share content across instances and interact with others.

Unless that person is on an instance the owner of your instance doesn't like.

Federation is a form of decentralization though? There's no central critical Mastodon server owned by some entity, anyone can make their own server. It's not like the only way to make something decentralized is to not have servers involved.

Your account is mostly (but not entirely) portable, and redirects works for handles so handle's can be portable as long as you pick and use a webfinger instance under your control or someone willing to redirect. It's nowhere near perfect and especially the ability to move accounts badly needs improvements, so I'm not suggesting it's good enough, but it's slowly heading in the right direction (the ability to move accounts - currently only with the cooperation of the original server - is fairly new)

There is already some basic functionality to alias handles, for example @shane@reustle.org points to my mastodon.social profile. They still need to add a bit better support until it works fully, though. For example, when I tag this alias handle, it gets replaced with the m…social domain. This would let you jump around instances without changing your handle.

But... What is Bluesky? What is a handle?

Bluesky is a new social media platform people currently excited about. And a handle is a... shortcut that points to you, and when people uses this shortcut, you get excited.

They used to call that "getting fingered".

"rustybolt" is your handle on HN.

https://en.wikipedia.org/wiki/Bluesky_Social

Jack Dorsey is creating distributed Twitter

Not Dorsey, it’s Jay Graber and the rest of the team. Dorsey created the team and is board member but doesn’t have control over the operation.

Also, they aren’t creating distributed Twitter, AT protocol is the infrastructure for any social decentralized service we will want to create in the future. Bluesky is the first use case, but the team is building something way bigger than just the microblogging application.

It’s worth checking ATP docs, they are quick to read and well made: https://atproto.com/guides/overview

> but doesn’t have control over the operation

And who owns the Bluesky company that is paying the wages ?

Jack is a board member and has contributed funding but does not have a majority control and doesn’t “own” Bluesky.

If I host my own identity server can I bypass the need for an invite? Maybe it's this? https://github.com/bluesky-social/indigo

Yes you can run your own PDS, but not federate. Federation hasn’t been completed yet but is expected to be done in the coming 1-2 weeks.

Go to https://github.com/bluesky-social/atproto, clone it, build and run via the makefile.

There are already some instances running but as said they do not federate at the moment.

Understood, thank you!

Err what? Federation is the whole point. This is just twitter again without it.

Perhaps the aim is the idea of federation but in practice have everyone sign up to server they control.

It’s in development… Federation is expected to be done in the coming weeks. The team is very small and is dealing with a lot of things at the same time.

But nobody asks that you join now, just wait for federation if that’s what you care about.

Can you share what limiting growth helps with?

- Easier to keep up with increased demand on server resources due to user growth.

- Screwing something up impacts 100k people and not 10M people.

- Users have some expectation of "hiccups" in something presented as a beta product.

- Prevents bots from taking over the platform as the anti-spam / anti-abuse systems mature.

Why are you spreading worry over a couple weeks?

Mainly because I doubt it’ll be a couple of weeks. Saving the hard problems to the end is not how you do software engineering and this reeks of people who don’t know what they are doing.

Also, I kinda want this to fail. Mastodon is the right way forward from the twitter debacle.

I don’t understand. Don’t you want people to have choices? Some will want to move to activitypub, others to atproto. Some will stay on centralized platforms. Why would you want another option to fail?

And you may want to look at the team and how they justify their choices before arriving to a conclusion.

Mastodon won’t scale

Mastodon doesn't need to scale. Scale is about maximizing revenue with dark patterns, SEO, clickbait, propaganda and dopamine loops. Scale is the cesspool of human hatred and stupidity. Scale is you and your data being the product. Scale is a cancer Mastodon and other decentralized networks can hopefully avoid.

The only thing Mastodon has to do to "win" is continue to exist and thrive in its niche while the lumbering,, centralized corporate social media dinosaurs choke to death around them.

It already did.

Hardly

It's pretty funny how this supposedly decentralized platform is currently invite-only.

It's not funny, it's called a smart rollout strategy by people who actually know how to build a decentralized social network that stands a chance of beating twitter.

I don't know much about the people behind it. What Twitter-scale decentralized social network did they build before to get that know-how?

Hi, i'm the guy who built IPFS and Filecoin which are moderately large decentralized networks, and both me and Martin Kleppmann are technical advisors to the project. Additionally, Jeremie Miller (of XMPP) is on the board. The core team consists of developers who have many years of experience working on decentralized technologies (Jay, Paul, and Daniel have been in that space for a long time) and the others have plenty of other relevant experience (Including Docker and the Internet Archive).

Sure, nobody has ever built a decentralized social network at scale before, but we're not blundering our way into this.

I was asking about their specific claim. People bring all kinds of genuinely impressive credentials to efforts like this and still can't pull it off. I've used just about every social network since the first, and it seems like the problems are always human, not technology. Social networks seem to bring together and amplify all the problems of every other technology. It's the final boss and no one's cracked it.

You gave me a list of people and technologies they worked on, but you didn't answer the question. How do you bring that together into a decentralized system that can absorb and succeed Twitter?

While I totally get where you’re coming from, its a bit of an unfair question, “how are you going to do the thing you are attempting to do??” Is hard to answer without just saying “watch and see”, but ill try.

From a technical perspective the architecture is very similar to Twitter or other social networks internally, just pieced apart with some cryptography added to allow different components to not have to fully trust eachother. Thats to say, the components individually scale the same as twitter does (probably better tbh, we’re building this with 2023 tech not 2005 tech). Im happy to dive into that more but I actually dont think the technology is the hard part.

The bulk of the work is culture and community building and maintenance. One of the biggest things we’ve been focused on getting right is moderation, and the federated architecture helps a lot here. Allowing “third party” labeling to be integrated into the experience seamlessly allows communities to choose their own way of curating their experience. Instead of relying on a single company to dictate “the rules” you just pick “the rules” you want and go from there. There’s obviously a lot more to it, so id encourage you to check out some of our other blog posts: https://blueskyweb.xyz/blog

Has the team written anything about the architecture and/or guiding philosophy of Mastodon vs. Bluesky? Scanned the blog but couldn’t find anything.

EDIT: I see https://atproto.com/guides/faq#why-not-use-activitypub was linked below, but it would be nice to read something a bit more in-depth than that.

I am still predicting that BlueSky is the real Twitter alternative. [0]

All it needs to do is to get rid of the invite system (early) and open up its web app [1] and you will just watch it grow faster than the rest of the alternatives, and over time Twitter users will naturally move to BlueSky.

What they got right is that they have both iOS and Android apps early and there is no 'choose an instance' mess, with proper search functionality and there's a official default server to avoid first impression confusion.

We'll see what the normal users (non-techies) will choose in a few months time once the invite system is gone and the web app is ready and how strong Twitter's network effect is against BlueSky.

[0] https://news.ycombinator.com/item?id=34137385

[1] https://staging.bsky.app/

Roughly half my Twitter feed is people ushering themselves and others over to Bluesky. Not just tech-oriented people, and the people offering invites are basically keeping up with the people asking but just barely. There’s also (some but) very little skepticism from people checking it out. I think the only chance it doesn’t succeed is if people have trouble reconstructing a sufficient portion of their existing networks.

Disclosure: I’m just an observer, I could probably get an invite if I asked for one but I’m enjoying seeing it play out without any special treatment, and I don’t participate much on Twitter so I’m definitely not going to add much to any new Twitterlike platform.

It's interesting how different bubbles we're in. I can't recall having seen anyone mention Bluesky, but a fair proportion of the people I interact with on Twitter either are now both on Mastodon and Twitter or have moved fully.

I think the only chance it doesn’t succeed is if they do what clubhouse did.

If it's truly open, there'll be two-way bridges and/or the good bits will get adopted elsewhere and there'll still be just one Fediverse.

It feels like such a waste that they're not trying for interop from the start, though.

Federation is still planned, but by the time it happens, there will be (a) a critical mass of users on the original server, including high-profile accounts (b) more consideration of UX under a federated model.

It may be that the official app defaults to the original instance, perhaps with a de-emphasized way to switch it. It may also ask for favorite topics first and suggest an instance based on that.

However the onboarding works, I'm confident the solution will be cleaner than Mastodon's. Lessons will have been learned about how clunky federation can be and how much problems it causes for features like search and recommendations.

The main reason search and recommendations are clunky on Mastodon is user resistance against being more like Twitter. As someone who'd like it to be more like Twitter that is annoying, but people also need to understand that to a significant number of people not being like Twitter is a major selling point.

Yea, there’s a strong resistance because somehow the community thinks algorithms are only there for the benefit of investors and could actually be of benefit to users who don’t want to micromanage who they’re following.

As for search, it’s bizarre any community would be against such a basic feature.

From TechDirt: “I would talk about some of the cooler Mastodon algorithms I’d been finding, but after a few them then were yelled at by a bunch of Mastodon users, I’ve generally decided it’s not worth promoting those useful tools, for fear that people yell at them to shut them down.”

https://www.techdirt.com/2023/04/28/six-months-in-thoughts-o...

Personally I 1) want algorithms, and will do some for myself when I get a chance, and I detest reverse chronological, but I get the resistance given that Twitter has kept pushing it (e.g. you can switch to "following" but it doesn't stick - Twitter keeps switching back), 2) would like search. But to search what you need to realise to get why this resistance is there you need to keep in mind that a lot of early refugees from Twitter were marginalised users for whom search was regularly weaponised against them to harass. Search will come - there are regularly new attempts and a lot of the resistance will be less relevant as the userbase change, but to get buy-in it will need to provide a strong degree of opt-in and user control. Any system that fails to provide that will fail to win over those users who see that control as a strong reason to use the Fediverse.

> All it needs to do is to get rid of the invite system

Exactly. The hype will be dead by the time people can actually join.

If we look at the example of Clubhouse, the invite system just pissed a lot of people off. So by the time they finally opened up the app to the public, the goodwill of the potential userbase was spoiled.

Invite systems feel bad and hurt your relationship with your future users.

So who is Bluesky, and do they matter?

Do they have more market share than Mastodon, etc.?

They absolutely don't matter at this point in time, and the only buzz they get are from Twitter users asking for an invite code to use their half-finished product.

A fair amount of influencery types from Twitter have created an account already, but only time will tell how many of them are going to stick around.

Bluesky is currently invite-only closed beta, so it's not gonna be competing in market share for a while. There's probably around 30k-50k people there right now.

> Domain Name System (DNS) acts like a phonebook for the internet

I wonder if this analogy doesn't become increasingly inscrutable for younger readers, because phonebooks aren't a thing anymore.

It also seems to me that you don't actually have to know about IP addresses to understand why domain names as handles could be useful.

I'd compare domain names and IP addresses to street addresses and GPS coordinates. We could just drop all street addresses and numbers and just use GPS coordinates, but that'd be a massive pain in the butt to use. So we'll just keep to simple, human-readable text instead.

But there's not really a mapping between them. Combined with GP's suggestion that it isn't really necessary to understand IP addresses (GPS coordinates) it works well though - you have some address, you follow signposts starting from the bottom to the broader area, culminating in road name signs and a number on the door. (i.e. 'the town is this way' road sign is like 'authority for ycombinator.com is blah')

The important thing to understand is that the domain name system provides an authoritative source of information linked to the domain (DNS entries). One type of such information is IP addresses, but that is not really relevant in this context. I haven’t looked at the AT protocol, but in principle a domain doesn’t even need to have an IP address in order to provide information about handles and fediverse identities (only the DNS server needs an IP).

I'm just talking from a pedagogical point of view, the current phonebook analogy isn't meant for us anyway.

It's a contact list for the internet.

It seems I'm the only one that didn't know of the AT protocol and Bluesky. Any differences to Mastodon?

> Any differences to Mastodon?

https://atproto.com/guides/faq#why-not-use-activitypub

Can someone who understands these things compare the tech BlueSky is using to Nostr?

One thing about Nostr is that there is no authentication to retrieve data. So the data can be spread far and wide, without permission.

This can obviously be both good or bad depending on what your use case is!

I think that BlueSky has authentication so that the data only is retrievable on the server specified by the user.

Because of this, I think BlueSky is better for personal social use cases where the user wants to maintain control and feel a bit more safe.

Someone should ask ChatGPT first and then we can judge the output versus that of an actual human being.

this would be pretty nifty. Wondering about the implications for domain ownership - feels like that aspect can be a bit tricky / ownership isn't always clear to non-tech folks. But conceptually very pure.

About half the content on Mastodon is usually complaining about Twitter yet this week the attention turned to Bluesky. What a depressed cynical bunch they are.

Several have found the TOS, screenshot it, and wildly proclaim that "Bluesky will own all your content!", all commenters gullible enough to accept this proclamation. Whilst the TOS is just the standard legalese needed to run a user-generated content site. These people are incompetent or misinformation agents, or both.

They zoom in on a missing feature and declare the product DOA. Whilst it is very obviously a beta.

They found "nazi content". It was actually a user replying to some progressive post expressing their dislike for the BLM movement. A raw opinion, not one I personally agree with, but not even close to "nazi". But even if you do think it's out of line, it's a bloody social network.

They go on to bash the moderation options of Bluesky, which I honestly find refreshing (if they actually work, that is). The idea is that the user can pick per controversial category to hide, warn, or allow. But the fact that you can chose "allow" is a problem, according to them. Except for porn of course, because the anarchist furry sex worker should most definitely not be censored.

Oh, and also, Musk is a nazi and so is Dorsey. None commenting seem to have a clue how these two characters relate to Bluesky, but better be safe than sorry.

It's just one bad take after the other, expressed by sour miserable people without investing a second in what they're so confidently judging.

I don't have any stake in Bluesky, but I feel for teams releasing amidst such hostility. If they can pull of nomadic identity, "chose your algorithm", functional federation, moderation without tyranny, we're looking at something quite exciting.

> About half the content on Mastodon is usually complaining about Twitter yet this week the attention turned to Bluesky. What a depressed cynical bunch they are.

No it’s not? You’re just following people that talk about that, I don’t see any Twitter/Bluesky discourse on my timeline

Roughly 0% of my feed is full of that kind of talk. Why would you choose to have a feed like that?

You're describing humanity, lol

Why won't Bluesky allow use on the desktop instead of only mobile?

You can point your web browser to https://staging.bsky.app

The team is too small to develop and maintain even an electron desktop app or something like that wrapping the existing react-native-web SPA. But this leaves space for fancy third-party apps, or integration into multi-protocol desktop apps, as needed.

I'm really excited about bluesky, but mobile-only is a non-starter for me.

Is developing a third-party frontend with full functionality possible, given that (AFAICT) there's a permissioned element to the community?

The staging area would not accept my invite code. I got an error message that said "Invite code not accepted. Check that you input it correctly and try again."

Is your code in the format of bsky-social-xxxxx? If so, they've been revoked and replaced with longer codes because people reported that their codes getting brute-forced.

Source: https://staging.bsky.app/profile/jay.bsky.team/post/3juhjacx... (the CEO)

Thanks for replying; I don't know anyone else who has an invite. Yes, mine is in the bsky-social-xxxxx format. I checked my email but I don't see a follow-up invite.

I can't see anything there, it asks me to log in.

It asks for an invite code, or there is a waitlist? Is it invite only/exclusive or something like that?

its currently an invite-only beta, but i feel like we've dealt with worse randos than late night hacker news commenters, so here you go: bsky-social-55rkz-5aago

Are invites given to waitlisted users in batches in FIFO order? What are my chances if I've just put my email down now?

I have an invite, but I don't quite want to install it on my phone yet.

If that’s an offer I’ll take it from you. I’m currently trying to evaluate the service on behalf of my company…but do not have an invite to…evaluate the service.

My email is gutsy.03rhino@icloud.com. Thanks.

Haha. Thanks. It's mid day here. Couldn't use the code. Looks like someone else beat me to it. But that's okay. Very kind of you. I think I will check it out later then.

Would be really appreciative of anyone who could send me an invite :)

My contact info is in my profile.

ActivityPub atleast can use HTTP. To force HTTPS is not the way forward:

https://datatracker.ietf.org/doc/html/rfc2289

To rely on another centralized solution (DNS) is not the way forward either:

http://radiomesh.org

HTTP is insecure. There is no reason to use HTTP anymore now that a secure alternative exists. If you are making a new protocol there is no reason to support HTTP because there are no legacy systems still using it.

You didn't click that link?

Maybe you didn't understand it?

Simplicity is a good reason to avoid HTTPS, also freedom and economy.

30% of internet is still HTTP.

100% of non-stupid internet is still HTTP.

Security is not needed in the base layer. You can superpose it.

>100% of non-stupid internet is still HTTP.

  $ curl -I 'http://datatracker.ietf.org/doc/html/rfc2289'
  HTTP/1.1 301 Moved Permanently
  Location: https://datatracker.ietf.org/doc/html/rfc2289

I understand you are being snarky, but this actually proves my point.

How far down the road of uniform waste of energy have we not gone when public specifications are encrypted.

After 4 years of HN defending Googles war on HTTP, these are the arguments I'm still met with.

I think this is the end of the road for me on HN.

>You didn't click that link?

I did.

>Maybe you didn't understand it?

I did, but it is only for protecting passwords where HTTPS protects the privacy and integrity of every request and response.

>Simplicity is a good reason to avoid HTTPS, also freedom and economy.

If it's so simple that it is insecure I would say that it is too simple. HTTPS helps with freedom and the economy because people no longer have to trust their network providers to be good actors. They can shop knowing their orders are private and their payment information is secure.

>30% of internet is still HTTP.

This is questionable, but most people don't use that many HTTP sites. 97% of the time people spend on the web is spent using https [0]. The web is trying to get rid of HTTP. Bruesky adding support for HTTP is just introducing unnecessary tech debt.

>100% of non-stupid internet is still HTTP.

I'm not sure what you mean by this considering how ubiquitous HTTPS is.

>Security is not needed in the base layer. You can superpose it.

Which is what HTTPS does. It's built on the insecure layer of UDP for HTTP/3 and TCP for the previous versions.

[0] https://transparencyreport.google.com/https/overview?hl=en

I guess you need to have the creativity to extend the link knowledge with encrypting the data with the OTP.

Ubiquitous in corporate hell? Try humans doing real work, they don't use HTTPS.

No HTTPS forces you to comply. If you make your own security on top of HTTP it's optional.

>with encrypting the data with the OTP.

This is just a worse version of HTTPS. It provides no way to share the password with the host securely for your first connection with them.

>Ubiquitous in corporate hell?

Look at the site I linked most people are using HTTPS.

>If you make your own security on top of HTTP it's optional.

Which is a problem since people running sites may not invest in security. By banning HTTP you raise the security of the entire platform.

Nothing allows first connection security.

Google wants you to need HTTPS, that is what they sell.

From Chrome to GCP.

What “real work” involves computers and does not involve HTTPS/TLS over a public network?

“Security is optional” is not a valid approach these days.

I clicked the link, understood it and have no idea what its relevance is to HTTPS.

OTPs is not going to prevent governments, internet service providers, cafe owners etc from being able to intercept traffic and determine exactly what a user is posting. Which is not something anyone should want from a social network.

lol, you are concerned by interception (gov and isps have root certificates) but not about where the data is stored?

With OTP you can easily encrypt your data so nobody can read it inflight over HTTP.

I guess you need to have the creativity to extend the link knowledge with encrypting the data with the OTP.

HTTPS is about encryption with no preshared secrets, and proving the origin’s authority (the CA part of TLS).

OTP is about authenticating clients, using a preshared secret established by unspecified means.

They’re completely different things. It’s like you’re comparing Apple (the company) and Orange (the city in NSW, Australia).

Cleartext HTTP is bad for various reasons, one of which is that pervasive monitoring is an attack: https://www.rfc-editor.org/rfc/rfc7258.html.

"encryption with no preshared secrets" that does not exist, never have and never will.

The RFC seems to presuppose that there has been an initial trust setup (since it says the the client has a pass-phrase already). How do you setup that that initial pass-phrase without TOFU?

You cannot solve this unless you send a pigeon or trust some higher power.

Certificates are a scam.

My solution which is convoluted and relatively insecure if you have a persistent MITM is to require a password change that you can encrypt with the old password, then the MITM has to remember the old password to know the secret.

But you are right that OTP only are safe after the secret has been shared. Just like all crypto including HTTPS and SSH.

For HTTPS we have setup a infrastructure to solve that. Without similar steps for your OTP solution it will never catch on. Why not advocate for something like DANE if you do not like the current PKI setup?

The steps are for most people to stop using what the governements and companies provide/enforce.

HTTPS is _not_ more secure in any way. The lock icon is an illusion.

As for the technical reasons:

- Big-ints are not trivial in js.

- DNS is centralized.

How do you encrypt data with one-time passwords?

How do you prevent man in the middle attacks if you're not using https?

https://datatracker.ietf.org/doc/html/rfc2289

It's also quantum safe for eternity.

Reply on news.ycombinator.com