Open Identities

A week ago I sent Anders an email to talk about the commonalities between the projects we’ve both got going on in relation to digital identity ownership.

We’ve decided to recreate and continue that conversation in public so it’ll be easier for other interested parties to participate as well.

Hey Anders,

I first learned about your Obligator project via your HN post some months ago. I’ve been paying close attention to the identity space since early last year when I wrote a series of posts about reclaiming my digital identity, which first alluded to my plans for OIDC in a product called Weird:

This weekend I posted a long follow-up to that post, laying out the standards-based path forward for Weird as a catalyst for digital identity independence:

I suspect quite a bit of what I’m talking about in that last article to be “in your lane”, especially the emerging standard known as FedCM. It’s essentially the latest variation of the IndieAuth spec which you’ve implemented in Obligator in some capacity, but it has a better chance at first tier browser adoption since it’s being proposed by Google/Chrome devs.

I’d love to get an asynchronous dialogue going with you about your aspirations for LastLogin and how that might align with what Weird is trying to do.

1 Like

Hi Erlend, thanks for reaching out! I’ve really enjoyed reading some of your writings that you linked. I agree, we should talk more.

Very glad to be hearing from you!

In anticipation of your followup I’ll take the liberty of sharing a few more details from my end.

Weird has remained in the prototyping phase for the past two years, but things are moving along quickly now. More on that later but in short: we’re building a modernized take on neocities / gh-pages, that’s as easy to use as Linktree.

As mentioned in my last blog post, we’re using Rauthy as our OIDC foundation. It’s not quite as minimalistic as your very impressive 3500 lines of code, but it shares the obligator ethos of being eminently self-hostable; a small instance of it can run with a mere ~20mb of memory. Just as important, Rauthy is also self-sustainable because it’s being developed as a byproduct of Seb’s (the maintainer) full-time job.

The latest release that came out today (next will probably be v1.0) also added support for ‘Upstream Login Providers’ (starting with GitHub), enabling us to support the same kind of onboarding flow you’ve demonstrated on LastLogin.

Seb isn’t getting into the business of service-ifying Rauthy since he’s happy with his current setup, but he’s very open to collaborations with ventures like Weird. Given your passion for OIDC as an enabler of digital self-sovereignty as well as your willingness to build all the way up to user-facing services to make your tech accessible, there’s an exciting possibility space for us to explore here.

sorry this ended up so long…

Thanks for the followup. Here are the things from your emails and posts that most resonated with me:

  1. Weird profile pages. I think this is an excellent way to get people started with self hosting

  2. Rauthy. This is an excellent looking project that I hadn’t heard of. Seems likely I could have used it instead of writing obligator.

  3. Network of shared purpose. Loved this. This problem is getting worse. rauthy is a great example. If we had some sort of a search engine for what people are working on we could avoid a lot of duplicate effort and maximize our effectiveness in open source.

  4. FedCM. This is interesting. I hadn’t heard of it. I’m a bit concerned that they don’t spend more time comparing to Mozilla Persona. They really only mention it in passing. But it does seem to have some potential.

Let me tell you a bit about my current vision.

I’m primarily interested in human-scale software. Software that people run for them, their family, and friends. For example: media servers (Jellyfin/Plex), chat/forums, file storage, calendars, etc, and a million things that haven’t been invented yet.

I think it’s best for this sort of software to be run on your own hardware, with e2ee. An old laptop or phone would be ideal. The problem is that self hosting is way too difficult for the following reasons:

  1. Domain names are too hard to register and manage.

  2. Networking due to NAT and firewalls. IPv6 isn’t going to save us because you still don’t have a reliable protocol for opening a port.

  3. Software is too hard to run. Docker has improved things but you can’t expect the average person to learn docker. Even if you could, automated backups and updates are still unsolved.

Here’s the solutions I see:

  1. I’ve taken my first crack at solving domains with I’ve learned a lot since launching it and I think it’s going to get rolled into 2 in the future.

  2. I believe tunneling is the solution. This is my current side project focus. I’m working on a service similar to ngrok/Cloudflare Tunnel, but designed for self-hosting. Main difference is it will be built on a simple, open protocol, be very simple to use (Windows GUI app), offer e2ee, and provide high speeds and data caps intended for streaming video. I have extensive experience with this sort of software, having long maintained this list (GitHub - anderspitman/awesome-tunneling: List of ngrok/Cloudflare Tunnel alternatives and other tunneling software and services. Focus on self-hosting.) and written several of my own tunneling implementations. Note that Tailscale could also be a compelling solution to this, but I think requiring all users to install a VPN app to access any services is a significant downside.

  3. I believe a Windows GUI app can be made that would let you install a large catalog of web services, quickly expose them over the internet using the tunneling solution in 2, protecting them with something like obligator/rauthy for SSO. This app would manage backups and updates for the user. I have a decent prototype working using WLS2 and docker, but there’s a lot of work left to get it reliable and seamless. I decided to focus on launching 2 first to hopefully get some awareness and money flowing.

Ok, so here’s where I see our work intersecting:

Given that 2 is my main focus right now, here’s what I’m currently doing. There’s a bit of a chicken/egg problem with my vision. Trying to build both the self hosting app and the tunneling service is too much to bite off. It makes more sense to start with the tunneling service. Especially since that’s a fairly obvious source of revenue. The problem is that an extra simple tunneling service isn’t much better than all the other tunneling services because the apps themselves are still too hard to run.

I needed to build something that was useful on its own. So I decided to build an app that provides tunneling + file storage (using my GemDrive project ( + obligator.

So the idea is you run this app, go through a quick OAuth2 flow to tunnel a domain to your local app, and you now have your own web drive on your own domain that you can use for sharing files, hosting websites, etc.

I hope this will be compelling enough to get some traction, but there’s a good chance it won’t be and I’ll have to go back to implementing 3 in it’s entirety, or at least integrate with a few other apps such as Jellyfin, which is actually quite easy to run on Windows.

However, I think your Weird/linktree concept might provide an alternative compelling use case. Allowing people to host their own simple profile page may grant a sense of ownership that helps get them started hosting more services.

I realize you’re more focused on a hosted offering currently, but I think we should keep talking. I’d love to hear your thoughts on my ideas.

1 Like

I heckin’ love long, thoughtful replies Anders, so no need to ever apologize for that!

If we had some sort of a search engine for what people are working on we could avoid a lot of duplicate effort and maximize our effectiveness in open source.

Exactly! Glad this resonates with you :slight_smile:

FedCM. This is interesting. I hadn’t heard of it. I’m a bit concerned that they don’t spend more time comparing to Mozilla Persona. They really only mention it in passing. But it does seem to have some potential.

I have a similar concern with their lack of comparison to IndieAuth. On that note, you appear to have implemented something along the lines of the IndieAuth approach in your Anonymous OAuth2 auth.

That’s interesting, since when I brought up the possibility of implementing IndieAuth in Rauthy I was basically told that “it is not oidc compatible” because it “specifies a custom profile over oauth”. That might still be correct, but what I was trying to get at is whether or not it’s possible to do anything equivalent to what IndieAuth solves for, i.e. any form of web sign-in.

FedCM appears to enable the type of “Bring Your Own Identity Provider” solution I was talking about. And unlike Persona or IndieAuth, it’s on track to real browser adoption, which is key:

I’m primarily interested in human-scale software. Software that people run for them, their family, and friends.

I think it’s best for this sort of software to be run on your own hardware, with e2ee. An old laptop or phone would be ideal.

That’s pretty much the ideal I seek as well. We might just differ a bit on how ubiquitous this kind of setup ought to be. I’m of the opinion that even in the best-case-scenario of distributed, self-sovereign infrastructure, only 1/100 people should be ‘self-hosters’, for the same reason that only a tiny percentage of us know how to repair a car, sew clothes or grow food. There’s just too much stuff to know how to do for any single person, so it’s more efficient to pool our resources and abilities together in a community of mutual aid.

What’s most important is that no one is barred from doing any of this stuff if they so choose; that’s how we onboard new craftspeople and ensure redundancy (lower bus factor). One modern computer can easily provide essential services for ~100 people. No need for everyone’s machines to be consuming power 24/7 just to keep their website running. But everyone’s computers keeping backups of their own stuff? absolutely!

I’m fully on board with all of your problems & solutions. Love what you’re doing with, I hope we can build an integration for that into Weird.

My only note is the Windows app; seems unnecessarily limiting. By far the most avid self-hosters out there are Linux users, so a cross-platform app makes more sense to me. E.g. a Tauri app built with widely accessible web technologies.

The Tauri-based Spacedrive might even be pretty close to what you want in Gemdrive already, but maybe yours is more web-native?

Lastly, nice to know that you like Solid, because Rauthy already supports Solid-OIDC.

I’ve actually only implemented one small idea from IndieAuth, which is not requiring client registration. IndieAuth is a complete OAuth2 profile. It’s a good protocol, but I think OIDC isn’t that much more complicated and has way more adoption.

I’ve done a bit of experimenting with this in obligator. Basically trying to figure out what is that absolute simplest way to prove you own a domain/URI. Definitely want to continue working on this, but first we need to make it easier for people to actually control domains…

IndieAuth at least doesn’t require any browser support. It’s pure OAuth2. Persona is confusing to me. It seems like it would require browser support, but I read a lot of things mention a JavaScript polyfill. Not sure how that would work.

I agree it shouldn’t be a requirement to participate on the net, but I also think a much higher percentage of people should be empowered to self host. I think the key for my vision is that it needs to become far simpler. Hosting shouldn’t be any more difficult or less secure than running an app on your phone. And I believe that is achievable.

The problem with the ~1/100 approach is that for things like identity, you’re probably trusting someone close to you to run your login server for you. That one “nerdy cousin” in the family. Same for your ActivityPub instances, storage, etc. Although it’s awesome that this dynamic is now built on real trust, I think it’s problematic because that person is actually far more incentivized to violate your privacy than a big tech company, who mostly just want to target you for ads. Imagine you have a family Mastodon instance. Your nerdy cousin’s dad thinks you’re talking about him behind his back and asks nerdy cousin to check the private messages.

The solution I want in this case is that it’s trivial for everyone to run their own Mastodon instance. Then private messages are truly private unless one of the participants themselves betray that trust. You can achieve similar with something like Matrix but at an order of magnitude higher complexity cost. It’s unnecessary if we simply make it as easy to host as it should be.

Certainly. The windows app is simply the focus because it would reach the most new self-hosters. Anyone using linux is likely to already be able to figure out how to use docker themselves. My prototypes so far have been built on egui (rust) and gio (golang).

Yeah Spacedrive looks much more comprehensive. GemDrive attempts to be the minimal layer possible on top of HTTP to provide filesystem operations. Does Spacedrive have an HTTP API for accessing the files?

I do like solid. I think it’s too complicated for my needs (which is why I made GemDrive), but I’m hopeful that they achieve their linked data world domination dreams. Solid-OIDC has some good ideas.

1 Like

:wave: Hey there! I’m the one developing Weird at the moment, and wanted to get in on this great discussion. :wink:

One thought I had in this space, is that it would be cool if we could enable something of a combination:

  • Other people should be able to host the things for you easily
  • You should be able to host the things for yourself, as easily as possible, but it will only ever get so easy, things are difficult if you want reliability.
  • You should be able to easily move you hosting to other providers.

I would love it if the applications we use could be hosted in an automated fashion so easily that there could be multiple cloud providers that could host my stuff for me, and I could move between them without struggle. And if I wish, I could also move to my own self-hosting.

I would like to blur the line between “self-hosting” and cloud hosting, by having cloud services that could host what you want for you, as easy as installing an app. In this way, the user takes responsibility for deploying their website where they want.

So the user may not SSH into their own cloud server, but they still “own” their website hosting. I would love to give cloud hosting the user experience of an app store.

This seems maybe related to the Solid project, which I haven’t tried out yet, and I’m not sure why I haven’t heard more about it. I need to check that out more. My initial impression is that it isn’t getting mindshare, maybe because it needs to be presented better.

Also Sandstorm is another example, but they went too dramatic with their sandstorm “grains”. Deploying a whole CodiMD instance for one markdown note, or a whole RocketChat for one chat room isn’t a good idea.

Part of my interest in WASM components is the possibility they might provide for us to actually host apps and plugins that easily in a cloud-agnostic, fully automated fashion.

Maybe something like a universal UI for tons of different domain provider APIs.


That’s what I keep thinking. I feel like everybody, even if they don’t run it locally, should be able to own their own apps. Apparently there are limitations using a single-person mastodon server, but that’s a problem with ActivityPub and/or Mastodon protocols, not a problem with the idea.

Ideally, we all own our own data, while still being able to get the same kind of great experience interacting with the rest of the internet.

Welcome @zicklag! I’ve bumped you up to a full member since you come referred by @erlend_sh.

I think we are aligned on a lot. While I believe the ability to self host is important, it’s not the core principle. The core principles are ownership, control, privacy, and security. As long as providers can offer privacy and security, and it’s easy to migrate between providers, I fully support people hosting their content in the cloud, and would even recommend it as the default choice.

I suspect the reason you haven’t heard much about Solid is that they seem to be focused on enterprise customers, and honestly that might be the best approach for them. But I also think they have a fairly complicated, highly abstracted set of protocols. I believe I’ve looked through most of their specs, and I still don’t know what a basic file GET request would look like.

I agree. I see Sandstorm sort of as the platonic ideal of self-hosting. Basically the way things should work, but not practical for performance and logistics reasons. Any solution that requires all apps to be drastically modified is a non starter for me. At least until self-hosting is proven as a large market. Then maybe there will be room for a platform like Sandstorm to gain developer mindshare. It offers some really cool features.

I think a simple OAuth2 protocol for delegating domain control is all we really need. Take a look at my demo on DomainConnect should be this but it’s turned out very corporate-y.

Yep. ActivityPub has a lot of potential, but as currently used I think it’s missing a lot. I really don’t understand why Mastodon doesn’t make it trivial for you to bring your own domain. There’s been an open GitHub issue for years. That feels like table stakes for me for anything decentralized. Especially after they’ve had so many issues with instances going down and people losing their accounts. Also, it’s crazy that I have to have a different account for each type of app, ie Mastodon, Lemmy, PeerTube. All servers should be “universal” ActivityPub instances that can handle any type of message, and then there should be a client-to-server protocol for accessing them. There’s already such a protocol defined in the spec, but apparently no one uses it. Instead everyone just accepted the Mastodon API as de facto.

I’m hopeful that Bluesky creates some competition to get some of these things fixed, because I don’t see any reason why they can’t be.


TIL about

Feels a bit like the IndieBits version of Weird :grin:

1 Like

Here are several of the self-hosting projects I’ve seen that are similar in UX to the vision I have. Do ya’ll know of any others? @zicklag you might find PikaPods particularly interesting if you haven’t heard of it before.


Yeah, PikaPod probably comes the closest to what Weird is doing, in that they’re not trying to get people off the cloud. Instead they try to make cloud services less locked in and equitable, including by sharing profits with their upstream dependencies the same way we plan to.

Where we still differ from all of the above is that Weird wants to be akin to a Google Workspace (formerly G Suite) for a certain type of indie netizen (just like is for another), rather than an App Store with countless options to choose between.

Thanks to OIDC/FedCM however, the two are in no way mutually exclusive, since any of our hand-picked add-ons could still be replaced by external integrations. We just wanna have the bare essentials covered in a single package so that people who aren’t likely to venture beyond the defaults will have everything they need.

Just as there’s no conflict between narrow curation vs wide assortment, so it is with cloud vs locally hosted as well. There’d be nothing stopping any of those local hosting platforms from offering Weird as yet another option.

That said, making Weird work on the platforms listed above would be more involved, since Weird isn’t a single app but rather an app-composite. It needs to be that because it aims to cleanly weave together disparate components of digital identity which can’t be contained in a single monolithic app, nor can they be cleanly separated out into Unix-like modules, because every ID standard is a moving target.

For instance, in order to maintain a uniform profile on both Mastodon (ActivityPub) and Bluesky (ATproto), keeping them in sync requires an additional mediation layer like bridgy-fed. Special handling is a prerequisite for a seamless user experience that can compete with the Googles and Facebooks of the world.


This reminds me of a question I had about Weird.

How would you compare it to open source LinkTree alternatives like LinkStack or LittleLink? My understanding so far is the main differentiator is that you plan to have Weird operate as decentralized FedCM IdP. Am I on the right track?

That’s the gist of it, yeah. But also:

  • Tie in a series of other online-identity services as add-ons that can be optionally added to ones profile, e.g. ActivityPub, ATproto, blog (RSS), email etc.
  • Reclaim data from existing social sites. See for example how PolyWork does it it for LinkedIn. We wanna do the same thing, starting with GitHub.
  • Lastly, zicklag is delving into some WebAssembly magic to enable a brand new kind of ‘ meets GitHub Pages’ personal website paradigm. That’s really just a cherry on top of everything else though, and more of a v2.0 thing that won’t block the essential value proposition of ID + webpage.
1 Like

Love it. How would these add-ons work exactly? For example, what would the ActivityPub integration look like, and what functionality would it provide?

EDIT: Ohhh I think I understand better after looking at that link. That’s what you mean by the Google Workspace comparison. You’re planning to provide a curated set of services.

1 Like

Hey all! Sam Goto here, editor of FedCM!

I ran into this thread by accident, just following links from the FedCM repository and ran into this community!

There is much to like about this thread and this community, and I think we’d have more interests in common than not!

I posted this recently [1] to kick off a discussion on having help us develop the IdP Registration API, which was, ironically also noted here in this thread.

I just wanted to stop by to say “hi” and make myself available in case you all see opportunities to collaborate!

[1] Any chance IndieBits would be interested in allowing users creating accounts with their own IdP?


Welcome @samuelgoto! I replied in your other thread. Definitely interested in collaborating. Let’s keep the conversation going.

1 Like