@aaronpk @cleverdevil I'm not sure that adding native support in Indigenous for IndiePaper is the right step now. With https://github.com/cleverdevil/Indiepaper-macOS/pull/3 and the fact that every url in Indigenous allows you to open a ShareSheet, it doesn't make as much sense to me to bundle IndiePaper when IndiePaper (and other future services) can just have their own app in the Share Sheet.

Any thoughts for or against that train of thinking?

I think the only real outcome of this item would be being able to select a channel to have offline caching of posts.

@aaronpk can confirm. But it’s OK — it’s fun!

@aaronpk ok done

@aaronpk Cool! Thanks for checking.

@0x1C3B00DA

@aaronpk Hey, sorry to reply to a random post, but I don't think your site accepts bare mentions from Mastodon.

I think there's something funky with your AP implementation and Pleroma. I've been following you for a few days from my pleroma acct, but haven't received any posts from you.

@aaronpk Perhaps I misunderstood and need to read carefully. Perusing https://indieauth.com/ what I got was "This is a reboot of OpenID that requires you to create a webpage and link to it".

Perhaps that's not at all related to "IndieAuth" that we're talking about here (I didn't read your article yet, but I will now).

@jhabdas I wouldn't.

Total tangent, but here goes...

All Authentication Sucks

For years I've been working on a protocol I call OAuth3 (but I'd like to come up with a better name). It's like a peer version of OIDC or a convenient version of IndieAuth.

However, there have been a number of roadblocks and challenges. Having something work peer-to-peer (decentralized) and be convenient, is neigh unto impossible (but it is possible).

The problem with all existing auth solutions is that they're in one of two camps: Proprietary/Centralized (OAuth2 implementations) or complicated for a non-technical user OpenID/IndieAuth.

What Could Succeed

The way I believe that peer authentication will succeed is by providing a solution that primarily executes on the client device (keypair authentication) but, by default, syncs the public keys to a shared server (with a centralized well-known server as the default), and uses a static page (or 3rd party app if on a phone) - no server APIs required to function - in essentially the way a browser plugin (or native Facebook/Google OAuth on phones) works to manage the exchanges.

Ultimately, browsers need to adopt such a protocol, but it most be open and compatible between browsers. The same is true for smart phones. Until then, the centralized server would serve as a "broker" to serve the user's preferences to other client-side apps.

Most importantly, people need to be able to login like they're used to. It must be easier than the current solutions, not more difficult (and how better to make it easier than by removing the most frustrating - and least secure - part of login: passwords).

What it might look like

First Login on a Device

1. I click "Login"
2. A pop-up to "generic-auth.org" opens up (better branding, but you get the idea)
3. The user types in their email address (or domain name)
4. The part after the '@' (if email) is checked for a /.well-known/peer-auth/index.json
   • on 200 OK, redirect to that with ?subject={email} for the next step and save the user's choice
   • on 404 continue using generic-auth.org
5. I get a push notification on my device (or an email with a "magic link")
   • also, generic-auth.org could link to facebook, twitter, google, etc (though a true peer-auth site could not as that would require having a developer account)
6. I click the link in email (or the "Allow" option on the push notification) and I'm logged in (or, if using 2FA), I put in a passphrase or totp code
7. I accept any grants (email address, photo access, etc) as needed
8. I'm now logged in
   • The static app on generic-auth.com (or my custom auth site) caches that this site is allowed login

Secondary Login on Device

1. Behind the scenes the app loads a hidden iframe or postmessage to generic-auth.org
2. The app is either told to use generic-auth.org, or the peer auth the user supplied before
3. The app is given a pseudonymous pairwise identifier and short-expiry token without any interaction
4. The user is simply "logged in" with 0 interaction
5. The app silently renews the token (completely client-side, no server implementation), as needed
6. If necessary, a grants dialog appears asking for my email address, photo access, etc

Logout

1. When the user clicks "log out" in any web app (or app) that is passed via iframe or postmessage to the client-side and all private keys are deleted.
2. This means that client-side tokens cannot be renewed (as they were securely generated with client-side private keys)
3. Likewise an iframe or postmessage is opened for each of the list of sites which have been granted a token, causing their short-lived tokens to expire immediatley
4. The generic-auth.org server (or the peer auth server) are notified that they may remove "Chrome on Jon's Macbook Pro" (or whatever) and its public keys from the list of authenticated devices.

Security

• No cookies, only tokens
• Client-side token generation
• Short-lived tokens
• Optional (but default) sync of public tokens and of grants per app/site
• Only Facebook has a properly secure login that could feasibly be used on its own as-is
  • Twitter, Google, etc do not support PPIDs and are therefore insecure by default and cannot provide any information that could be used for encryption, etc, as all of the ids are shared among all apps/sites

But That's not a PERFECT Solution!

If you're on one side of a chasm and you want to migrate a host of people to the other side, you need a bridge. Something like generic-auth.org (in the hypothetical scenario above) acts as that bridge. The migration would be complete when browsers and phones natively support open-protocol peer-based authentication that doesn't require 3rd party apps to bridge the gap anymore.

Until that time you have the problem of OpenID/IndieAuth if you go for the "Perfect" peer solution - it requires too much knowledge and effort to intentionally use it. My mom is unlikely to create a website and link it to her other accounts with HTML tags.

The truly "perfect" solution then is the solution that people who don't care about technology and who don't understand the risks with their current login and authentication setups will adopt out of convenience, and perhaps a sense of individuality or pride, but certainly not for being the most technically correct solution.

The Catch-22

Peer-to-Peer can either be convenient for end-users or convenient to develop. It simply can't be both.

The saving grace is that if it's implemented in JavaScript and used in native apps through a web view, we only need a single implementation for the client-side and only 3 to 5 APIs for the server side (sync public keys, send email / push notifications, sync pairwise grants) - none of which require knowing anything about security or keypair signing and encryption - just opaque files, simple messages, and plain-old JSON.