search

kitsune-soc / kitsune

🦊 (fast) ActivityPub-federated microblogging
https://joinkitsune.org
Other
291 stars 19 forks source link

Minimal user agency #377

Open erlend-sh opened 8 months ago

erlend-sh commented 8 months ago

minimal definition of user agency:

  • Own your ID
  • Own your content
  • Own your contacts

https://subconscious.substack.com/p/the-minimal-definition-of-user-agency

I wonder if it’s possible to accomplish this in a way that doesn’t require #190 upfront.

Just having

..would already be a minimal version of ID ownership.

The usage of a domain ID by an apub server just needs to be something that can be revoked, I.e. by not having your DNS be pointing there any longer. Could be reinforced further by https://github.com/mastodon/mastodon/issues/24066

Minimally owning ones content and contacts is just a matter of having these backed up in a third party storage (like Noosphere or Solid), right?

erlend-sh commented 8 months ago

The completion of #399 and emergence of the kitsune-oidc crate makes more possible another possible avenue to consider:

Make Kitsune possible to run as just an auth server (identity db). And, conversely, just a send/receive server (pubsub pipe). Or both.

It takes a lot for me to be bothered with the overhead of self-hosting, but if I could take proper ownership of my federated identity and its authorized app personas by self-hosting it, I’d probably start doing that.

I don’t think I’ll ever wanna bother with the pipes on my own; I wanna outsource that to the most fitting host-collective. I wanna self-host something like a kitsune-auth and outsource the rest to a kitsune-pipes

What this would enable is a two-tiered hosting setup. It’s a bit like splitting Kitsune up by the metaphorical duality of body and soul.

Point being that ‘everyone’ (at least as far as the early-adopter techie crowd goes) takes care of their own soul (auth), which can be plugged into any larger body-organism (pipes) of one’s choosing.

By separating out the auth-layer of Kitsune to let users self-host that subsection of the app in the most lightweight way possible, you empower users to interface with the rest of Kitsune from a point of self-sovereign digital identity.

p.s. An interesting thing about self-hosted auth is that you don’t even need it to be persistently online. There are use cases for it, but none that are essential.

For the fundamental act of logging into places, your self-hosted auth only needs to come online whenever you are trying to access an online space that asks for your authentication.

erlend-sh commented 8 months ago

An OIDC provider like https://github.com/sebadob/rauthy by @sebadob could be a good fit for this type of dual setup, since it comes with its own UI.

The AGPL complicates the possibilities for direct coupling/bundling though.

sebadob commented 8 months ago

I already talked to @erlend-sh and in case of Rauthy and I am not fully sold on the license yet. It may become more open with an Apache or MIT.
the AGPL was chosen to just have a bit more freedom in the early phase, since I am a single developer and did not know how fast I could get it up to a point, where I wanted it to be.

With the v0.17 now, I got most of the stuff ready, that I wanted to have in case of features. I am about 1-2 minor versions away from having it "complete" before I can think about a v1.0.0 RC

aumetra commented 8 months ago

Binary distribution (i.e. a potential Kitsune installer that installs and configures rauthy during the installation process) should be fine.

And it's actually funny that you mention licensing talk, because technically we also haven't fully reached consensus yet on whether we want to stay with the current MIT license or migrate to a different, potentially more restrictive, license

(well, "restrictive" is a rather harsh word. Let's say "copyleft license")

aumetra commented 8 months ago

@erlend-sh it would be great if you have a more concrete description of the deeper integration you would like to see between rauthy and kitsune.
Right now the integration that would be 100% possible is to bundle it as an installation option in a possible future installer, where it could be marked as an installation option.

Or do you mean something else?

erlend-sh commented 8 months ago

Frankly, I don't know exactly what I mean yet 😆 The emergence of Rauthy has got me rethinking some of my preconceptions about identity in the fediverse.

I'm trying to imagine how the fediverse model of identity could change if we relegate the fediverse instance to a second-order identity manager as opposed to first-order, primary identity manager.

Here's an approximation of what I'd like:

The persistent granting of access might depend on DPoP:

The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token. This constrains the legitimate sender of the token to only the party with access to the private key and gives the server receiving the token added assurances that the sender is legitimately authorized to use it.

..which has been implemented in Rauthy: https://github.com/sebadob/rauthy/issues/132

Reframed in the context of Solid interop here. Solid is not a prerequisite for any of this to work though. The storage layer could just as well be built directly on top of Rauthy, or a lighter protocol like Solid-lite.

erlend-sh commented 7 months ago

Muddling through with some additional context here:

But really all of this boils down to the MVP flow detailed in the comment above, wherein I want to:

erlend-sh commented 7 months ago

Restated my case here: https://socialhub.activitypub.rocks/t/autonomous-identity-for-the-pluriverse-based-on-oauth-oidc/3675