Email or username:

Password:

Forgot your password?
Emelia's posts Post Back to profile
Top-level
Emelia πŸ‘ΈπŸ»

> There's no reason an ActivityPub server should demand to control the end-user's private keys.

Whilst I agree in principle, in practice, management of security keys is a right pain in the ass for end-users. Sure, you could do authentication via a PAKE (OPAQUE / SRP6a), and then derive a key-encryption-key from the users' password, but that introduces a lot of complexity.

If a user looses their security keys, then they can never continue, there is no password reset option there.

16 October at 21:18 | Open on hachyderm.io
8 comments
Emelia πŸ‘ΈπŸ»

> I think a lot of people want 'Account Portability' because what they really want is Single Sign On.

This may be true, and hopefully all the work I've been doing around pushing Mastodon towards a more standardised OAuth system that borrows elements from OIDC helps here. For instance, I've just done the pull request for a userinfo endpoint, which would more easily enable this "single sign on” approach.

github.com/mastodon/mastodon/p

16 October at 21:22 | Open on hachyderm.io
Emelia πŸ‘ΈπŸ»

I think something @bengo does kind of miss in this article is how these decisions would impact end users, would it simplify things or add more complexity? β€œWait, now you mean I need to choose an authentication server AND a mastodon server???”

For non-technical people, a lot of these proposals would absolutely loose them. Only technical minded folks even know that public/private keys are used in Mastodon.

16 October at 21:24 | Open on hachyderm.io
bengo

@thisismissem hey I didn't miss that. FWIW I actually don't think new users should have an 'identity server' at all (until they want one). but we do agree new users shouldn't have to make the choice as you present it. longer discussion I'll write up later.

17 October at 17:18 | Open on mastodon.social
bengo

@thisismissem this is what I was getting at with:
> Something that shakes out of unbundling Authentication from Social Servers and even Actor Servers (e.g. using cryptographic authentication and not a actor-server-dependent authentication scheme) is the ability to fully author signed social content without an internet connection

17 October at 17:19 | Open on mastodon.social
Emelia πŸ‘ΈπŸ»

@bengo aah, okay. The article was pretty technical, and for a lot of users they just want to get setup and start posting.. and then stuff happens later and their like "ugh”

17 October at 17:26 | Open on hachyderm.io
bengo

@thisismissem my goal is to get it so users can get setup and start creating posts without talking to a server (identity or social) *at all* and only replicate to one or more servers when they are ready/able/connected to share those posts with others. i.e. inkandswitch.com/local-first/

17 October at 17:36 | Open on mastodon.social
Marcus Rohrmoser 🌻

Hi @bengo @thisismissem,
love the idea but AP being a protocol of 1:1 delivery that wants direct contact to each recipient doesn't sound feasible for multiple followers which may be offline.

And each delivery must be mutually visible from the internet for the http signature callback.

17 October at 20:34 | Open on digitalcourage.social
Mike Macgirvin (dev)
Delivery of signed, portable objects (ala FEP-ef61) don't actually require http signatures. The only reason to still use them is to glean the identity behind fetch requests which have no signed payload and maintain compatibility with legacy ActivityPub applications like Mastodon.  

And in any case, authoring a post and delivering  post are completely different functions and there's absolutely no reason they need to take place on the same device.
Delivery of signed, portable objects (ala FEP-ef61) don't actually require http signatures. The only reason to still use them is to glean the identity behind fetch requests which have no signed payload and maintain compatibility with legacy ActivityPub applications like Mastodon.  
17 October at 21:05 | Open on fediversity.site
Go Up