GWGThe question I was trying to answer last night, to go broader than IndieAuth.com is how many people delegate or want to delegate IndieAuth to a server not under their control? I want to stop maintaining that code in WordPress in favor of just the local endpoints, but want to consider points of view.
[tantek]For a WordPress plugin especially where you can transparently implement the protocol necessary to make someone's website their direct IndieAuth IdP, it makes sense to deprecate and remove IndieAuth/.com as an option ASAP
Loqiindieauth.com provides an authorization server that you can use with your website in order to log in to IndieAuth and Micropub apps https://indieweb.org/indieauth.com
[schmarty]GWG: without something currently in the works, it seems a lot more likely that the existing service will go away first, leaving a gap until that more-workable thing exists.
[schmarty]sites and services that use IndieAuth purely for identification (like the wiki, owncast comments) can keep barriers low for users by adding relmeauth. it complicates those services, but that's one of the major benefits of something like indielogin dot com (for apps who can get on the list to use it or self-host).
sknebelaaronpk: maybe you should rename it to something long and descriptive - after all a user only has to put the URL in their site once, its not something you need to remember and type. "RelMe2IndieAuthAdapter.com" ;)
[schmarty]but folks who want to play with microsub or add micropub to their site need a real-real IndieAuth provider and without indieauth dot com there isn't really any alternative to running one of a handful of server implementations. or rolling your own.
[schmarty]i was surprised to find that, for me, packaging doesn't really seem to be the issue. there are so many things not fully covered by the IndieAuth spec, or not widely implemented in the wild, that it's easy to pick defaults that don't work or are really annoying to use.
[schmarty]taproot/indieauth is largely built around the more modern spec as-written, along with some security-minded defaults like short-lived tokens, and when i actually started using it i was fighting that constantly.
barnabymm yeah that makes sense. have you documented/captured these issues somewhere? sounds like it could be worth reviewing to see if we can do anything about it
barnabybut (assuming it works as it is?) I’ll definitely link to it from taproot/indieauth, you’ve covered a lot of useful documentation which I lazily directed people towards the spec for
barnabythe issue about taproot/indieauth insisting on fetching client_id especially sounds interesting. does that often cause problems in your experience?
sknebelalso if you build things that check for/insist on newer parts of the spec and it fails, note that down and file issues if possible. a lot of our ecosystem is running on stuff that just works(TM) and isnt touched much, so its easy to miss if new changes actually require updates
[schmarty]i vaguely recall local development of indieauth clients was failing. possibly taproot/indieauth not checking whether a client_id resolves to localhost IPs (which must not be fetched)
sknebelre above, if there is supposed to be an open relme2indieauth-adapter, updating the set of supported providers would also be nice. right now its effectively only github I think?
GWGaaronpk: Can you use indielogin as part of an IndieAuth.com replacement somehow? For example, some service you authenticate to using indielogin but isn't indielogin itself? Or is that crazy?
aaronpk[snarfed]: oh maybe this is different for just sign in with google, but if you want access to any google data you have to go through a bunch of approval hoops
aaronpkindielogin.com isn't doing rel-me-auth as described by the spec, it's looking for the rel-me link from your website to the silo, then checking that the OAuth API returns the same user ID after the user logs in
[snarfed]mastodon isn't practical...just because the indieauth server would have to use the API to create a client first? that is more work, but it's not prohibitive, right?
aaronpktho the other option is sending a mastodon DM with a one-time code (like SMS/email) but that means I have to run a whole activitypub client which is worse 😂
[tantek]GWG, interestingly, with everyone at IWC focusing on session discussions and hack projects that prioritized what was most important to them for their personal site, there were a couple of hack projects for making sure past private support worked and then improving the styling of private / limited audience posts to that they were more obviously private/limited to those viewing them especially in a stream of otherwise "public" posts. I believe
GWGI have this vision where each endpoint is a self-contained file and registers itself with the metadata endpoint instead of a lot of hardcoded values and conditions.
GWG[snarfed]: It is essentially, load file, add endpoints to metadata. Right now, the metadata endpoint has a bunch of conditions. It's messy. You are thinking optimization, I'm thinking...easy to read/understand/update
[tantek]the expansion I'm considering is say you have text like http://example.com/@userfoo - that currently auto-links to http://example.com/@userfoo. What I'm considering adding is if you similarly put @example.com/@userfoo or say @example.com/user/foo, having those link to the https version by the same reasoning as plain domain @-linking.
[tantek]any concerns about broadening the use of '@' as a prefix to a domain/path to basically mean a shorthand for https:// for the purposes of auto-linking?
[snarfed]for arbitrary user input, agreed on identity/security. for people you @-mention yourself though, presumably they generally won't be misleading or malicious etc, so emphasizing domain equally to username may be less important
[tantek]Yes [snarfed] I deliberately chose "@example.com/@userfoo" because it looks a lot like an @-@ but isn't one. It's an @ in front of a schemeless URL
[tantek]I could see a little special treatment of domain/@username to turn the link text into @username@domain but I’m not sure how helpful that would be
Loqi[preview] [jenn schiffer] tomorrow i am kicking off a new weekly live stream on the @glitchdotcom youtube channel. join me at 2pm ET as i:
* share what’s new on glitch
* show some apps you made that i love like my own children, and
* code (scary!) my submission to this mon...
Loqi[preview] [Jenniferplusplus] @tchambers
It seems like the trend in dynamically typed languages is to just let dynamic typing do the hardest parts.And I'm sure there are some projects actually using JSON-LD processing. I explored doing that, but I find it's more trouble than it'...