Giters

kitsune-soc / kitsune

🦊 (fast) ActivityPub-federated microblogging

Home Page:https://joinkitsune.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Minimal user agency

erlend-sh opened this issue · comments

commented

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 mastodon/mastodon#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?

commented

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.

commented

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.

commented

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

commented

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")

commented

@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?

commented

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:

  • I'm running Rauthy on erlend.sh (actually hosted at id.erlend.sh or whatever) as my primary identity manager.

  • I sign up for joinkitsune.org to start microblogging.

    • I authenticate with my erlend.sh domain via IndieAuth (or at least a process nearly identical to it).
      💡 This functionality could be worked around initially by having joinkitsune.org preemptively trusting erlend.sh as a signin domain
    • I start posting on a custom apub.erlend.sh domain.

  • All of my actions on the joinkitsune.org server/pipes are mediated through erlend.sh as the authorizer of each action.

  • joinkitsune.org is a trusted keeper of my follows and other meta-data, but I have my own copy in something like a rauthy-activitypub extension. This extension will also notify me if Kitsune has quietly removed some of my follow-connections as a result of defederation.

  • Should joinkitsune.org disappear in a puff of smoke one day, I can shift apub.erlend.sh to another Kitsune host (e.g. my own) without needing any kind of forwarding in place at joinkitsune.org .

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: sebadob/rauthy#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.

commented

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:

  • Self-host my own OIDC-powered identity on my own domain
  • Log into Kitsune with that identity
  • Keep a backup of rudimentary Kitsune data on that identity, I.e. my contact list.