Hacker News Reader

Comment by mg | Hacker News Reader

Is there already a Fediverse mechanism to let people log into 3rd party sites? Like "Log in with Twitter/Google/Facebook" but "Log in with ActivityPub"? That would be pretty cool.

I like the aspect of ActivityPub that you can own your identity to the same degree to which you can own a domain.

It would be cool if it would be possible to log in to third parties as @you@yourdomain.com via the ActivityPub protocol.

Thinking about how to implement it technically .. one simple way would be to just send a magic link to @you@yourdomain.com via DM.

Hmm... that could actually work. Your username on - say - Hacker News would then simply be your Fediverse handle: @you@yourdomain.com

The same would work with emails of course. Most people don't want their email publicly visible though. But they would probably not mind using their Fediverse handle as their username.

View on HN

Mastodon can work as an oAuth Provider, I believe.

But the interest thing is that I'd like to do the opposite: I'd like to be able to use my own id (openID, public key, DNS record, whatever) and use it as my identity on any activitypub server. Then the servers would be truly a simple hosting provider.

Using oAuth would only allow users in who use an ActivityPub instance that supports oAuth.

I for example will probably use something much simpler than Mastodon. As I will actively look for an ActivityPub software that is lean and does one thing well: ActivitiyPub.

Microblogpub looks promising:

https://microblog.pub/

Pleroma is what you are looking for, then.

Not sure. The code and the interface of Pleroma are way more complex than microblogpub.

I tried a Pleroma instance and the UI had sticky elements. Sticky elements make me scream and run.

I really like the HN interface. My ActivityPub node should have a similar interface. Plain HTML, rendered serverside, reload to update.

Sorry, now I am just realizing that we are talking about totally different things. What does the frontend of Pleroma have to do with how authentication is done on a ActivityPub server?

Pleroma is compatible with the Mastodon client-server API.

Using Pleroma will make lots of homeservers block you because the main developers and some major users of the platform are right wing (like KiwiFarms) so lots of Mastodon homeservers consider it to be Nazi software and will block you outright just for using it

This is incidentally why I'm not developing an Activity Pub homeserver myself -- I have no interest in having users doxx my politics simply because I'm interested in social networking protocols.

Personally, my hobby is no longer computers, and it definitely isn't FOSS -- I'm not trying to be the next guy blackballed from the industry for having the wrong thought about the current thing. That's also why I have a throwaway account here. Political activists working inside the tech sphere are savage and have no mercy, and I wish to have nothing to do with them. For me that mostly means: no ActivityPub, no Twitter.

So, because you think you will be blocked by some group (which will become less relevant as AP grows) you decide to do their job for them and silence yourself?

The only way to end this insanity is by having more normies running pleroma/soapbox/rebased, not by self-censoring from fear of the woke-mob.

The controversial site you mentioned is currently being blackholed by one of the major transit providers in the US, who are supposed to be neutral when it comes to internet traffic. This is the level of political interference from certain identity groups, disrupting the internet in a way that would usually only get done via the courts.

Best to remain neutral IMO and focus on building the tools for both sides irregardless of your own personal political stance. I really like the approach taken by instant messaging platforms, particularly Signal's approach of being e2e encrypted. That makes them not liable in most cases even in court to withholding information because they physically can't lol. It also means they'll have no way of deciding if they should censor right wingers / left wingers.

In a way this was also what inspired me to build Soul, though I get the appeal of being decentralized and all, I think we can still remain impartial by being an external provider with no access to any other information (e.g. user posts) besides user accounts and relationships.

Kind of... there is https://indieweb.org/rel-me which Mastodon does support and which can be used in tandem with https://indieweb.org/Web_sign-in

ActivityPub doesn't encompasse authentication or authorization.

Here is the spec: https://www.w3.org/TR/activitypub/

It explicitly defers auth to be implementation-specific: https://www.w3.org/TR/activitypub/#authorization

ActivityPub doesn't really offer a mechanism for it, but I am planning on building a service which will combine fediverse handles with OpenID authentication which I hope will work very similarly to what you want.

Is there a need for an additional mechanism?

Sending a magic link to @user@domain results in a 3 actions login:

1: User types "@user@domain" into the login form and hits enter.

2: User switches to their fediverse inbox

3: User clicks on the link in the DM

I have the vague feeling that this is the shortes possible path. Or does your solution make it shorter?

I think the shortest path would be to implement an industry standard federated authorization mechanism as OpenID.

But to be honest I don't fully understand your proposal, maybe I'm just missing how it's simpler. :)

In my humble opinion the double asperand is a visually atrocious abomination and wholly redundant. I hope this pattern dies quickly.

needs to be differntiated from email (or maybe not, i would prefer it if SMTP was just extended to be social)

what would be a better format?

I had the same reaction at first.

But after some contemplation, I changed my mind. It's not so easy to say if there is a better alternative.

We need way to say "This is a Fediverse users. Their instance is xyz.com and their username is abc". A way that easy to grok visually and also by software.

    abc@xyz.com - is alread taken for emails.

    xyz.com/abc - would be a link

    xyz.com@abc - is the wrong way round.

    abc*xyz.com - would work. But is it good? Hmm...

These are definitely better:

  @xyz.com/abc

  @abc.xyz.com

I'm not sure. I don't like @abc.xyz.com at all.

@xyz.com/abc has the nice benefit that it is like https://xyz.com/abc with only the https:// part is changed.

But "Written by @joe@someinstance.com" reads much nicer than "Written by @someinstance.com/joe".

Those are significantly worse, because they do not ambiguously state what @user@site does. This is such a minor thing to be up in arms about, aesthetically it looks fine and immediately communicates what it is.

I think this portion of the discussion on the ampersand satisfies the definition of "bike shedding", right? :-)

@xyz.com/abc is the best I've seen so far.

I think inverting this is also a sweet spot. It lets you drop context if on a locally federated node:

@abc/xyz.com

@abc[/xyz.com]

@abc

The username first prioritizes the human, and the host instance lookup can be added with tooling [1].

We should weigh ergonomics, visual distinguishability, ease of parsing from plaintext (important), ease of typing, visual aesthetics, simplicity, and extensibility.

We should collect dozens of candidate formats and weigh them on these (and more) dimensions.

[1] (eg. autocomplete that doesn't change the previous buffer, unlike, for instance, Google Docs chips).

There's really no reason not to use email addresses for this use case.

Consider,

http://username:password@www.example.com/path?query=1#hash

Reduced to the parts that would actually matter (because username and path are redundant for this use case, and no one seriously embeds passwords in URLs),

scheme://username@www.example.com

So it seems that the design challenge is baking the scheme into zero or one glyphs.

username@www.example.com

Hey, that looks like an email address! A URL is an extended email address, an email address is a URL with default values.

> There's really no reason not to use email addresses for this use case.

As elegant as that would be, confusion could arise.

Email and federated identities might be intersecting sets, but not are not guaranteed to be either subsets or supersets of one another.

The ambiguity of this seems problematic.

I disagree, I think we should demand that `username@domain.com` (coupled with a digital signature) be the one true way (TM) that services treat identity. Whether domain.com supports an email service, an HTTP service, or a social service is secondary. Standardized representation of the principal is the primary concern.

Twitter and Facebook represent the principal using their own alternative formats to assert ownership over the domain, not because they're good formats (@foo, fb.com/you). They've normalized the idea that the textual representation of the principal should be different between different services, but there's no fundamental reason it should be so.

Given decades of ~abc for a home directory and xyz.com/~abc/ URLs, perhaps the tilde could be put to use yet again:

    ~abc@xyz.com

It isn't as easy to type as @. In fact, my keyboard doesn't even feature a tilde written on any of the keys, so I make it appear solely from muscle memory.

abc@xyz.com is definitely not taken for email. It works as a HTTP url, or SSH logins and it can very well work for ActivityPub.

Reply on news.ycombinator.com