[HN Gopher] How to set your domain as your handle
___________________________________________________________________
How to set your domain as your handle
Author : carride
Score : 161 points
Date : 2023-04-29 03:26 UTC (19 hours ago)
(HTM) web link (blueskyweb.xyz)
(TXT) w3m dump (blueskyweb.xyz)
| mg wrote:
| 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.
| amadeuspagel wrote:
| If you have your domain pointed to a substack, you can still
| edit the DNS records, but you can't upload JSON files.
| cmckn wrote:
| How is running a web server for a JSON file easier than
| creating a TXT record in your DNS?
| mg wrote:
| 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"
| blitzar wrote:
| > 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).
| aaomidi wrote:
| But why
| bnewbold wrote:
| 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.
| mg wrote:
| 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?
| bnewbold wrote:
| 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.
| mg wrote:
| 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?
| vidarh wrote:
| 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.
| pcthrowaway wrote:
| 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.
| vidarh wrote:
| 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.
| wahnfrieden wrote:
| 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.
| vidarh wrote:
| 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.
| tedunangst wrote:
| 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.
| mg wrote:
| 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.
| tedunangst wrote:
| 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.
| mg wrote:
| 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?
| numpad0 wrote:
| 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.
| vidarh wrote:
| 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.
| sieabahlpark wrote:
| [dead]
| tedunangst wrote:
| 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
| mg wrote:
| 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.
| vidarh wrote:
| 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).
| mg wrote:
| 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?
| vidarh wrote:
| 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
| mg wrote:
| 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.
| vidarh wrote:
| 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)
| jeroenhd wrote:
| 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.
| mg wrote:
| 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?
| vidarh wrote:
| 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)
| mg wrote:
| 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..."
| vidarh wrote:
| > 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)
| [deleted]
| bullen wrote:
| 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
| charcircuit wrote:
| 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.
| bullen wrote:
| 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.
| pwn0 wrote:
| How do you prevent man in the middle attacks if you're not
| using https?
| bullen wrote:
| https://datatracker.ietf.org/doc/html/rfc2289
|
| It's also quantum safe for eternity.
| threeseed wrote:
| 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.
| bullen wrote:
| 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.
| chrismorgan wrote:
| 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.
| progval wrote:
| How do you encrypt data with one-time passwords?
| SahAssar wrote:
| 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?
| charcircuit wrote:
| >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
| bullen wrote:
| 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.
| Kwpolska wrote:
| 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.
| charcircuit wrote:
| >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.
| Hamuko wrote:
| > _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
| bullen wrote:
| 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.
| botanical wrote:
| It seems I'm the only one that didn't know of the AT protocol and
| Bluesky. Any differences to Mastodon?
| olah_1 wrote:
| > Any differences to Mastodon?
|
| https://atproto.com/guides/faq#why-not-use-activitypub
| [deleted]
| silasmcpherson wrote:
| 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.
| rvz wrote:
| 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/
| mmahemoff wrote:
| 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.
| vidarh wrote:
| 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.
| mmahemoff wrote:
| 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...
| vidarh wrote:
| 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.
| eyelidlessness wrote:
| 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.
| blitzar wrote:
| I think the only chance it doesn't succeed is if they do what
| clubhouse did.
| vidarh wrote:
| 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.
| olah_1 wrote:
| > 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.
| vidarh wrote:
| 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.
| stanislavb wrote:
| [flagged]
| mattkevan wrote:
| Also looking for an invite :-) My email is my username
| @gmail.com
|
| Thank you!
| _1tan wrote:
| Also looking to test the protocol. Mail is ,,ajabell (at)
| protonmail.com"
| anttiharju wrote:
| Would also love an invite! Insert @ in the middle of my
| username and .io at the end and you have my email.
| kyle_o wrote:
| Also hoping to score an invite, email is in my bio. Thanks if
| you can, and good luck to OP!
| seaghost wrote:
| I'm also looking for an invite. Could you send it to seaghost
| at gmail. Thanks!
| whyrusleeping wrote:
| pretty far down in the thread, hope no-one but you sees this:
| bsky-social-fupii-zizug
| howenterprisey wrote:
| I stole the code, sorry! I thought I was going to be able
| to generate more codes myself and my friend really wanted
| an invite, but it seems like there's a bit of a cooldown
| period first. I will email kyle_o the first one I get as
| soon as I can.
| troad wrote:
| I would much appreciate an invite too, if anyone were feeling
| generous! :) My email is on my profile.
| nf17 wrote:
| i would really appreciate an invite too. email is nfa379 @
| gmail
| marymkearney wrote:
| Would love to join also, and hope these requests don't get
| overwhelming. Thanks most kindly. mary @ marymkearney.com
| layer8 wrote:
| > 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.
| Hamuko wrote:
| 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.
| OJFord wrote:
| 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')
| layer8 wrote:
| 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).
| OJFord wrote:
| I'm just talking from a pedagogical point of view, the
| current phonebook analogy isn't meant for us anyway.
| Animats wrote:
| So who is Bluesky, and do they matter?
|
| Do they have more market share than Mastodon, etc.?
| input_sh wrote:
| 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.
| Hamuko wrote:
| 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.
| rustybolt wrote:
| But... What is Bluesky? What is a handle?
| nirui wrote:
| 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.
| thrill wrote:
| They used to call that "getting fingered".
| LatticeAnimal wrote:
| Jack Dorsey is creating distributed Twitter
| dgellow wrote:
| 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
| threeseed wrote:
| > but doesn't have control over the operation
|
| And who owns the Bluesky company that is paying the wages ?
| neilalexander wrote:
| Jack is a board member and has contributed funding but
| does not have a majority control and doesn't "own"
| Bluesky.
| [deleted]
| jwilk wrote:
| https://en.wikipedia.org/wiki/Bluesky_Social
| DANmode wrote:
| "rustybolt" is your handle on HN.
| lumenwrites wrote:
| Can someone who understands these things compare the tech BlueSky
| is using to Nostr?
| olah_1 wrote:
| 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.
| hammyhavoc wrote:
| Someone should ask ChatGPT first and then we can judge the
| output versus that of an actual human being.
| ericzawo wrote:
| Would be really appreciative of anyone who could send me an
| invite :)
|
| My contact info is in my profile.
| jimsimmons wrote:
| 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.
| Mattasher wrote:
| 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.
| vidarh wrote:
| 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)
| mort96 wrote:
| 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.
| RobotToaster wrote:
| >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.
| reustle wrote:
| 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.
| ryan29 wrote:
| 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.
| bnewbold wrote:
| 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.
| ryan29 wrote:
| 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.
| ryan29 wrote:
| 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
| grose wrote:
| 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
| dgellow wrote:
| 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.
| mnd999 wrote:
| 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.
| wahnfrieden wrote:
| Why are you spreading worry over a couple weeks?
| mnd999 wrote:
| 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.
| wahnfrieden wrote:
| Mastodon won't scale
| krapp wrote:
| 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.
| dgellow wrote:
| 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.
| wahnfrieden wrote:
| Can you share what limiting growth helps with?
| dymk wrote:
| - 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.
| grose wrote:
| Understood, thank you!
| jeroenhd wrote:
| It's pretty funny how this supposedly decentralized platform is
| currently invite-only.
| [deleted]
| gfodor wrote:
| 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.
| Kye wrote:
| 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?
| whyrusleeping wrote:
| 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.
| Kye wrote:
| 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?
| whyrusleeping wrote:
| 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
| archagon wrote:
| 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.
| wyclif wrote:
| Why won't Bluesky allow use on the desktop instead of only
| mobile?
| bnewbold wrote:
| 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.
| pcthrowaway wrote:
| 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?
| crossroadsguy wrote:
| It asks for an invite code, or there is a waitlist? Is it
| invite only/exclusive or something like that?
| whyrusleeping wrote:
| 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
| crossroadsguy wrote:
| 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.
| wyclif wrote:
| I have an invite, but I don't quite want to install it on
| my phone yet.
| testfrequency wrote:
| 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.
| [deleted]
| [deleted]
| [deleted]
| wyclif wrote:
| 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."
| ifvictr wrote:
| 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)
| fafqg wrote:
| I can't see anything there, it asks me to log in.
___________________________________________________________________
(page generated 2023-04-29 23:02 UTC)