#dev 2023-11-02

2023-11-02 UTC
gRegor joined the channel
#
GWG
aaronpk: What do you think the future of indieauth.com is?
#
GWG
[snarfed]: I meant the token and authorization endpoint there.
#
aaronpk
It's all coming down eventually, the question is just when
#
aaronpk
I should probably prioritize at least stopping new people from using it
#
GWG
aaronpk: I'm contemplating removing even the disabled support for it in the WordPress code.
#
Loqi
I agree
#
GWG
aaronpk: Do you know how many people are actively using it right now?
#
aaronpk
I have stats available
[chrisaldrich] joined the channel
#
GWG
Just curious.
gRegor, geoffo, gxt, angelo, [pfefferle], [tantek] and nertzy joined the channel
#
GWG
The 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
#
sknebel
agreed
AramZS joined the channel
#
GWG
I feel better about the decision now.
#
rubenwardy
what is indieauth.com
#
Loqi
indieauth.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
#
rubenwardy
ah good, doesn't replace indielogin
#
GWG
No, it predates it. Legacy service.
#
GWG
Back in the day, people thought indieauth.com, a reference implementation, was IndieAuth.
geoffo joined the channel
#
[schmarty]
i do worry that, without a free-and-hosted indieauth provider, barriers to indieweb participation will be much higher.
#
aaronpk
i'm not opposed to a free hosted provider, it just shouldn't be called indieauth dot com
#
[schmarty]
i haven't heard any discussion around _renaming_ indieauth dot com, tho. just shutting it down. 😅
#
aaronpk
well there are other reasons i don't like the architecture of it
#
[schmarty]
oh sure. it kind of worried me, as a newcomer to the indieweb, that it was a free *identity provider* run by an internet stranger
#
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.
#
aaronpk
that's one of the reasons i haven't just shut it down so far
#
aaronpk
I'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).
#
sknebel
aaronpk: 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" 😂
#
barnaby
I wonder how much work it’d be to make a .phar package you can just dump on a server and have it work
#
barnaby
I’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.
#
barnaby
mm 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
#
[schmarty]
just, uh, "code as documentation" 😅 https://git.schmarty.net/schmarty/belding
AramZS joined the channel
#
barnaby
ah very nice, I will look through that in more detail at some point
#
barnaby
but (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
#
barnaby
the issue about taproot/indieauth insisting on fetching client_id especially sounds interesting. does that often cause problems in your experience?
#
sknebel
also 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]
barnaby: fetching client_id definitely caused problems for me. iirc taproot/indieauth was treating fetching (and finding h(-x)-app data?) as a fatal error if any part of it failed, while the spec lists it all as "SHOULD". https://indieauth.spec.indieweb.org/#client-information-discovery
#
[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)
#
GWG
The newer parts of the spec aren't so new anymore
#
sknebel
relative to development activity they are
#
sknebel
re 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?
#
GWG
Is there anything else we could support?
#
aaronpk
gitlab
#
aaronpk
discord
#
aaronpk
google is almost impossible now
#
aaronpk
linkedin should be ok
#
aaronpk
oh and flickr
#
aaronpk
i should add some of these to indielogin.com
#
Loqi
I agree
#
[tantek]
Presumably we could file issues on IndieLogin for each of those
#
[tantek]
Perhaps Wikipedia or Mastodon as well since they support rel-me
#
sknebel
Mastodon, after last weekend: strava? ;)
#
GWG
aaronpk: 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?
#
[tantek]
Strava doesn't have rel-me support AFAIK
#
[snarfed]
aaronpk what makes Google almost impossible? I've been consuming it as a pretty stock OAuth client for many years now, it's still working fine. code: https://github.com/snarfed/oauth-dropins/blob/main/oauth_dropins/google_signin.py
#
[snarfed]
(OAuth 2 + OpenID Connect)
#
aaronpk
mastodon isn't practical
#
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
#
aaronpk
rel-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
#
aaronpk
indielogin.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?
#
aaronpk
i don't want to add mastodon because then I have to maintain a table of client registrations
#
[snarfed]
right, sure
#
sknebel
I wonder if clients actually do that
#
aaronpk
and handle all the edge cases that fall out of doing that, like what happens if a client is unregistered for some reason
#
sknebel
or just run through the same flow always
#
aaronpk
oh gosh
#
sknebel
especially native clients, do they even go through a server or use some device flow?
#
sknebel
and evne the web clients some are entirely client-side afaik?
#
aaronpk
this is why we have indieauth 🤦‍♂️
#
[snarfed]
Mastodon programmatic OAuth client registration has been surprisingly painless in Bridgy/granary. but still, understood
tbbrown joined the channel
#
[tantek]
right, the path for Mastodon is to get Mastodon to support being an RP
#
[tantek]
an IndieAuth RP
#
[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
#
aaronpk
oh, not really because at the end of the day i still have to support mastodon oauth for it
#
aaronpk
tho 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 😂
#
[KevinMarks]
also mastodon dm's aren't really dm's
#
aaronpk
what really is a DM anyway tho
#
[KevinMarks]
backs away from the ticket discussion again
#
GWG
Tickets scare people?
#
[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.
#
sknebel
yep. I think I even sent GWG a few tickets while I was trying out what various bits of old code do
#
sknebel
(found a hardcoded "send ticket to GWG script" that I triggered a few times)
#
[tantek]
we did record the demos session so once that's up you can watch the private posts demos yourself!
#
GWG
sknebel: You didn't tell me. I never set up notifications
#
GWG
Found the token in the log
#
sknebel
nice, so that still works on both sides :D
#
GWG
sknebel: I need to get back to my implementation. It is barebones
#
GWG
Also 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
#
GWG
I 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
It 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
#
GWG
I'm not going to speed weeks on it.
[aciccarello] joined the channel
#
[aciccarello]
Imagine if threads supported micropub?
#
[snarfed]
GWG ok!
[snarfed] joined the channel
#
GWG
[snarfed]: It is so I can iterate on the extension that shall not be named
neceve joined the channel
#
[tantek]
I am considering making '@' auto-linking more generic at least in CASSIS auto_link
#
[tantek]
as in, right now if you just have a domain, like http://example.com, that auto-links to the http:. but you can also have an explicit 'http://example.com' or explicit 'https://example.com'. and I already support @example.com meaning an @-mention of https://example.com/ — domain only, no path.
#
[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?
[nsmsn] joined the channel
#
[snarfed]
I like it
#
[snarfed]
I wonder if you might even go further and hide the domain in an <abbr> or something
#
[snarfed]
or title=
#
[snarfed]
may vary by site I guess. some people might want to equally weight domain, others dim it, others hide it altogether
#
[tantek]
Definitely not going to hide domain, as that's the most prominent for identity and security, same origin etc
#
[tantek]
This is for a single '@' only
#
[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
[nsmsn] joined the channel
#
[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
[nsmsn] and barnaby joined the channel
#
Loqi
[preview] [Jenniferplusplus] @hrefna I feel like people don't really grasp how long the ramp up is, and how completely impossible it is to implement federation incrementally. Maybe a visual will help some people?I've been at this for 4 months, and only just now approaching the "... https://media.hachyderm.io/media_attachments/files/111/342/546/179/105/411/original/63974da7f66ddfd4.png
#
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'...
#
Loqi
ok, I added "https://hachyderm.io/@jenniferplusplus/111343003922627346" to the "See Also" section of /JSON-LD https://indieweb.org/wiki/index.php?diff=90376&oldid=85048
AramZS, barnaby and jeremycherfas joined the channel