gRegor, geoffo, gxt, angelo, [pfefferle], [tantek] and nertzy joined the channel
#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
#GWG[schmarty]: I always thought the idea was to come up with something that was more workable long term.
#[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.
#aaronpkthat's one of the reasons i haven't just shut it down so far
#aaronpkI've been thinking about building a new version of it for a long time
#[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.
#barnaby[schmarty]: was it you who was working on an easy-install indieauth package based on taproot/indieauth a while back?
#[schmarty]barnaby: it was, haha. i don't think i'm gonna make it to "easy-install" 😂
#barnabyI wonder how much work it’d be to make a .phar package you can just dump on a server and have it work
#barnabyI’ve looked into doing that kind of thing but never actually tried it
#[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
#barnabyah very nice, I will look through that in more detail at some point
#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)
#GWGThe newer parts of the spec aren't so new anymore
#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
#aaronpkrel-me isn't necessary to add a site to indielogin.com, all that's required is an OAuth API and that your account at the silo has a URL
#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]ah sure, actually getting data. but for relmeauth, sign in alone might be ok
#[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?
#aaronpki don't want to add mastodon because then I have to maintain a table of client registrations
#[tantek]aaronpk, I was more curious if there was some way to use the rel-me support in Mastodon to build something, but perhaps that's too complicated
#aaronpkoh, not really because at the end of the day i still have to support mastodon oauth for it
#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]traffic tickets certainly but scary tickets are perhaps more for #indieweb-chat
#GWG[tantek]: I thought he meant the Ticketing extension
[Paul_Robert_Ll] joined the channel
#[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
#[tantek]sebsel and sknebel worked on that. See the Demos notes for more.
#sknebelnice, so that still works on both sides :D
#GWGsknebel: I need to get back to my implementation. It is barebones
#GWGAlso want to refresh the IndieAuth code overall. I bolted on metadata and such and I think I can remove some redundancy
gRegor joined the channel
#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.
#GWGIt means when someone comes up with the next cool endpoint, it is just a few lines away
barnaby joined the channel
#[snarfed]how often are endpoints added? rarely, right? doesn't seem worth "optimizing" that much
#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]confused; your example was @example.com/@userfoo
#[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
#[snarfed](may still be useful to evangelize the distributed nature of all this though!)
#[tantek]Also keeping it more simple and predictable by not hiding anything
#[tantek]None of the existing CASSIS auto-linking functionality hides anything so I'd prefer to keep it that way. auto-embedding is different of course
#[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'...