#dev 2021-04-07

2021-04-07 UTC
KartikPrabhu, oedmarap, [tw2113_Slack_] and [tantek] joined the channel
#
@soMelanieSaid ↩️ Thank you for the kind words, Christine! Yeah, I think we're all still figuring out the UX around Webmentions. I need to get around to implementing a comment form on my site for those who prefer that mode of communication. :) (twitter.com/_/status/1379601065356627972)
#
@soMelanieSaid ↩️ Here's a couple resources on Webmentions if you'd like to learn more about them: https://daily-dev-tips.com/posts/goodbye-comments-welcome-webmentions-%F0%9F%99%8B%F0%9F%8F%BC%E2%80%8D%E2%99%82%EF%B8%8F/ https://alistapart.com/article/webmentions-enabling-better-communication-on-the-internet/ (twitter.com/_/status/1379601605276798976)
#
@JavaScriptFeed Adding Webmentions to a Gatsby site via @echojs #javascript #100daysofcode #webdev #webdevelopment https://jonkuperman.com/gatsby-webmentions/ (twitter.com/_/status/1379616265346506752)
#
@kkd Knownに投稿したstatusをTwitterへ自動でsyndicate（リンク付き）でやる方法がわからない。今はKnown->Micro.blog->Twitterという流れ。リンクがないとhttp://Brid.gyが元投稿と認識できないのでwebmentionが飛んでこない。 (twitter.com/_/status/1379620694548492290)
#
@kkd Knownに投稿したstatusをTwitterへ自動でsyndicate（リンク付き）でやる方法がわからない。今はKnown->Micro.blog->Twitterという流れ。リンクがないとhttp://Brid.gyが元投稿と認識できないのでwebmentionが飛んでこない。 (twitter.com/_/status/1379620694548492290)
KartikPrabhu, [scojjac], [tw2113_Slack_], jjuran, lahacker and tomlarkworthy joined the channel
#
tomlarkworthy I think I should be able to signin with "https://github.com/tomlarkworthy" if I have not got a homepage setup. Then the auth server can function as a normal federated login provider
#
tomlarkworthy actually I would say its a bug if the auth server does not consider the stating node on the relme graph as a potential identity provider
#
tomlarkworthy starting node
lahacker and danyao joined the channel
#
tomlarkworthy ok know issue: https://github.com/themattharris/RelMeAuth/issues/3
#
Loqi [cweiske] #3 https github links not supported
cjav_dev, zootella, shrysr_, lahacker, edsu, astrojl_matrix, forest[m], [KevinMarks], [arush] and ShadowKyogre joined the channel; ShadowKyogre left the channel
#
@mxbck ↩️ btw: @swyx hosts one of these here: https://github.com/sw-yx/domainblocklist can be used to filter out domains on your end, or block them in http://webmention.io (twitter.com/_/status/1379794309457850371)
[tantek], gxt, [asuh], [scojjac], shoesNsocks, kitt, [KevinMarks], shoesNsocks1, [manton] and joshproehl joined the channel
#
[tantek] tomlarkworthy, there's two things there. 1. I'd like to add github as a way to do RelMeAuth via your personal site (so when you use your personal site, your GitHub is one of the options used to validate your identity). And 2. That RelMeAuth prototype UI should a) detect when common silo profiles are being attempted, and b) have better error text explaining that's not the point of RelMeAuth 🙂
tomlarkworthy joined the channel
#
tomlarkworthy oh right, github is just not supported, ok. Still, according to the error message it does not attempt to use it as a provider at all. Thats the bug. Everynode in the relmeauth graph should be a candidate provider in my mind, it should not matter where you start the crawl right? They are all bidirectional links so I don't see the first one can't be a identity provider too.
#
tomlarkworthy it would lead to a lower friction for service providers if users do not need to create a homepage to use the service
#
aaronpk If you want to accept GitHub identities then that's fine but that's not relmeauth
#
tomlarkworthy no github URLs
#
[tantek] except "lower friction for service providers" is a negative. the whole point is to liberate users from depending on service providers for their longterm identity
#
tomlarkworthy not identities
#
tomlarkworthy I want a pathological relmeauth graph of JUST the github profile
#
tomlarkworthy the user is still identified by URL, its jsut theiur homepage IS the github profile
#
[tantek] teaching users to depend on a silo profile as their identity is teaching them to get comfortable with shackles
#
tomlarkworthy yeah its tricky to migrate them to their real URL when they set one up later
#
[tantek] an explicit statement about that in the Readme might help
#
[tantek] correct! migration later is harder
#
aaronpk tomlarkworthy: My point is that if they enter their GitHub url and then authenticate with GitHub there isn't really any RelMe involved at all
#
tomlarkworthy they is becuase their username was still a URL which is public information
#
aaronpk if you mean letting people click a GitHub button and then doing the actual RelMe check and using their own website as the resulting identity then that's a different story
#
[tantek] oh yeah that would be interesting too, and a different UX flow
#
aaronpk maybe it's not clear but RelMeAuth is from the rel=me link relation that describes a relationship between two URLs
ShadowKyogre left the channel
#
aaronpk So if there is only one URL in question there isn't a relationship to describe
#
[tantek] yup, more for the readme
#
tomlarkworthy I don;t think you shoudl insist the relme graph has to have at least 2 nodes
#
tomlarkworthy thats making the 1 node graph an unnecissary special case
#
tomlarkworthy your saying relme graphs of size one are not allowed, which is unnecissary friction for users who have not crosslinked their profiles yet
#
aaronpk ok if you want to argue the academic angle that's fine, but again with just a GitHub url you're just doing GitHub login, which is fine if you're okay with all the downsides but it's not RelMeAuth
ShadowKyogre joined the channel
#
tomlarkworthy but its not, becuase the 3rd party service provider is not sroting the user as a URL, not a github uid
#
tomlarkworthy from a compliance perspective its different
#
aaronpk There's actually even more issues with that
#
aaronpk A user's GitHub username can change
#
aaronpk so you shouldn't rely on it as an identifier
#
tomlarkworthy yeah so you end up taking their email address
#
tomlarkworthy which is where compliance issues start to really bite
#
tomlarkworthy I see the relme graph as an alternative resolving mechanism to email address
#
tomlarkworthy with the beatuy that its public information under user control and not confidential information under GDPR
#
tomlarkworthy So resolving a github identity to a public URL is still good, and leaves room for migration to a different URL later using the relme graph to say what other social profiles can be merged
#
tomlarkworthy at the moment, things like Firebase auth record all the emails, so social profiles can me reconciled using email address, but this is a problem for europeans.
#
tomlarkworthy ok I put the kids to bed
ShadowKyogre joined the channel; ShadowKyogre left the channel
#
tomlarkworthy RelMeAuth wiki: "input: a user identity (URL) to authenticate" So a 1 node relmeauth graph still encompasses the URL -> profile mapping, thats not valueless
#
tomlarkworthy service provides can key users by URL in their databases. NO CONFIDENTIAL INFORMATION IS PERSISTED
[fluffy] joined the channel
#
[fluffy] I think a bigger question is, why is RelMeAuth still being pushed as a thing that site/app operators need to implement themselves? IMO if you’re going to do RelMeAuth you should use indielogin.com to implement it (instead of having to implement all your own backends), and if you want a better identity story you should go straight to IndieAuth.
#
[fluffy] RelMeAuth is annoying to implement as a client (because you end up needing to get API keys and write code for all the supported silos) and IMO it causes a lot of confusion too
#
[fluffy] (that said I should probably add RelMeAuth support to Authl)
#
aaronpk tomlarkworthy: here's the problem. in order to accept a github url as a relmeauth identity you're going to need to go register for api keys on github, and then you'll use the github api to authenticate people, and you'll get back their entire github profile info in the response anyway. so you aren't really gaining anything by calling that RelMeAuth or by storing just the github URL instead of calling it
#
aaronpk github login and storing the github user ID
#
tomlarkworthy but the verification fo the github profile is done in-memory, so nothing hits long term storage.
#
aaronpk sure but that's the same whether you store the github url or ID after
#
tomlarkworthy yeah its only really a different story if you end up storing the github users email or not. I guess the github id as the suffix to their profile URL is also public info so thats no different to URL
#
tomlarkworthy but if you use Firebase authentication it always grabs the email and stores it on US soil
#
tomlarkworthy they do that for reconciliation across social logins
#
tomlarkworthy but maybe its jsut a bad implementation. I like with the relme auth graph there exists a reconciliation that does not rely on email
#
aaronpk that's also a potential attack vector depending on how the provider handles returning that email address. sometimes they'll return the email before it's been verified, so you can take over someone's account
#
tomlarkworthy I know several of them have a isVerified flag
#
tomlarkworthy but @fluffy I agree. Indielogin you still need to self host and spin up oauth clients for each provider, so if the service does not accept a vanilla github profile URL as a login, then you need to spin up a 2nd peice of infra for people who do not have homepages
#
tomlarkworthy which is annoying as you essentially have the right peice of infra sitting there but it doesn;t work with vanilla profile URLs even though the relmeauth spec technically shoudl cover it.
#
aaronpk i see what you mean now
#
tomlarkworthy If you look closly at the algorithm http://microformats.org/wiki/RelMeAuth#summary_algorithm
#
aaronpk ok i have an alternative explanation
#
[fluffy] Incidentally I just opened https://github.com/PlaidWeb/Authl/issues/93 since it seems beneficial to support RelMeAuth from Authl (which already implements the silo identity stuff anyway)
#
aaronpk yes, RelMeAuth technically could allow someone to enter and claim a silo URL with just one node on the RelMeAuth graph
#
Loqi [fluffy-critter] #93 Support RelMeAuth
ShadowKyogre left the channel
#
aaronpk however, that is not the intent of RelMeAuth
#
aaronpk separately, indielogin.com does not even claim to support RelMeAuth, it is specifically a service to log people in given their own website as their identity, using several different authentication providers (GitHub, Twitter, IndieAuth, PGP)
#
[fluffy] @tomlarkworthy I mean if you use indielogin.com as your login provider you don’t need to do a whole lot. It supports IndieAuth and some RelMeAuth providers for you.
#
aaronpk from a product perspective, indielogin.com explicitly wants to encourage you to use a URL under your own control as your identity
#
aaronpk it is not meant to be a generic authentication service that supports multiple platforms
ShadowKyogre joined the channel
#
[fluffy] right but the user setup for indielogin.com tells folks to do the RelMeAuth setup
#
tomlarkworthy When I try to use indielogin.com it tells me I don;t have a registered client, ergo, I have to self host it
#
[fluffy] like it never mentions RelMeAuth but everything it describes is basically RelMeAuth + IndieAuth
#
[fluffy] oh, right, you have to register the client, I forgot about that
#
aaronpk yes, indielogin.com is not meant to be a public authentication service
#
aaronpk it is used by indieweb resources
#
[fluffy] now I remember why I removed it from Authl 🙂
#
[fluffy] (well, that and it was redundant with IndieAuth)
#
tomlarkworthy I agree that users should use a homepage as their URL under a domain they own. But also, as a service provider, I don't want any more login friction than necissary, so I would want people without a homepage to be able to start straight away if they want.
#
tomlarkworthy Ideally, with a path to migrate later if we win them over on the homepage argument
#
aaronpk sure, that's up to you to decide for your own product, but that is not the goal of indielogin.com, or RelMeAuth
lahacker joined the channel; ShadowKyogre left the channel
#
tomlarkworthy like my point was that I thought it was a bug, but now I looked at the detailed algorithm its definately a bug
#
tomlarkworthy "start with a user identity URL (e.g from the UI, or from a cookie from previous login etc.) if the URL is an OAuth provider then try authenticating with it (we prefer the user's own site for auth)"
#
aaronpk a bug in what though?
#
tomlarkworthy thats from the wiki
#
tomlarkworthy the relmeauth implementation
#
aaronpk which?
#
aaronpk indielogin.com explicitly does not claim to implement RelMeAuth
#
tomlarkworthy ok my buig report was with the relmeauth prototype
#
tomlarkworthy http://microformats.org/wiki/RelMeAuth#detailed_algorithm
#
tomlarkworthy https://github.com/themattharris/RelMeAuth/issues/3
#
Loqi [cweiske] #3 https github links not supported
#
aaronpk aha another unfortunate naming collision 😂 a product named after the spec
#
tomlarkworthy no its the github repo pointed at by the demo from the wiki http://tantek.com/relmeauth/
#
tomlarkworthy the prototype said "any issues report to github" which I did
#
tomlarkworthy I thoguht it was a bug, now I read the spec, I am SURE its a bug
#
aaronpk agreed
#
aaronpk the spec is pretty clear that if the user enters a github url it should just use that
[email096] joined the channel
#
tomlarkworthy and in my opinion, a useful feature for service developers
#
aaronpk actually it may not be a bug per se
#
aaronpk it just might not be set up to authenticate via github
#
tomlarkworthy yeah it does not support github but in the error messages it did not even try and it lists everything it tried and github is not one of them when its the starting URL
#
aaronpk what i mean is that if it doesn't have github api keys then there's no way it can try github first
#
aaronpk so it's not a bug, it's just not implemented
#
tomlarkworthy yeah it does try the first URL, but it does not put it into the list of things it tried, https://github.com/themattharris/RelMeAuth/blob/ae930f04bfd6c1da52a1680cd17cc4d11d56cc06/lib/relmeauth.php#L51
#
tomlarkworthy yeah it prints out jsut the things it tried APART from the first one https://github.com/themattharris/RelMeAuth/blob/ae930f04bfd6c1da52a1680cd17cc4d11d56cc06/lib/relmeauth.php#L157
ShadowKyogre joined the channel
#
aaronpk for example if you enter a twitter.com profile it works as expected
#
tomlarkworthy damn, kinda fence post issue but for graphs.
#
tomlarkworthy great! so 1 node relmeauth graphs are supported even in the prototype
#
aaronpk yeah it's just not set up with github keys, which is obviously not something that could be expected
[chrisaldrich] joined the channel
#
tomlarkworthy so now I test with indieauth.com and that definately does not support "https://github.com/tomlarkworthy" but you are saying you don;t want to which is fine.
#
aaronpk indieauth.com is also legacy infrastructure at this point but yeah it also works that way intentionally
#
tomlarkworthy yeah its jsut the one I can test with so its handy
[aciccarello] joined the channel
#
tomlarkworthy for my fork of indielogin I probably will jsut becuase I think it is useful and it seems covered by the relmeauth spec.
#
tomlarkworthy I have three providers setup for testing here https://observablehq.com/@tomlarkworthy/weblogin
lahacker and KartikPrabhu joined the channel
#
tomlarkworthy dunno if you have a authl setup anywhere fluffy, if so I would add that too just for comparison
KartikPrabhu, ShadowKyogre, lahacker and PauloPinto joined the channel; ShadowKyogre left the channel
#
[fluffy] @tomlarkworthy Authl is a Python library I wrote for making multi-provider identity easier to get. https://authl.readthedocs.io/ and it’s what I use for login on https://beesbuzz.biz/
#
[tantek] I should clarify in the RelMeAuth spec that "user's own website" is literally the user's *own* website, a profile on someone else's website is obviously not owned by the user
#
[tantek] the RelMeAuth prototype working with Twitter URLs was a bootstrapping test I built up
#
[tantek] not any part of RelMeAuth support per se
#
Loqi it is probable
#
aaronpk [tantek]: was "if the URL is an OAuth provider" in step 2 here foreshadowing IndieAuth? http://microformats.org/wiki/RelMeAuth#detailed_algorithm
#
[tantek] yeah
#
[tantek] today I'd rewrite that part in step 2 to "if the URL is an IndieAuth provider "
#
[tantek] because that's less setup to implement
[tw2113_Slack_], lahacker and [schmarty] joined the channel; ShadowKyogre left the channel
#
tomlarkworthy ok thanks for clarifying
ShadowKyogre, lahacker, [KevinMarks] and [jeremycherfas] joined the channel; ShadowKyogre left the channel
#
[schmarty] aaronpk: i'm running a somewhat out-of-date Aperture so this might be moot. recently i added several feeds with no indication of errors from Aperture, but the entries count stayed at 0. i found that they weren't in Watchtower and tracked it down to an issue with my Watchtower setup.
#
aaronpk hmm
#
aaronpk i think the link between the two isn't great. i keep considering rolling watchtower into aperture so it's just one thing to manage
#
[schmarty] it seems like Aperture should have caught the 5xx from Watchtower and let me know somethign was up?
#
[schmarty] (i read through the last couple years of Aperture logs and don't see anything about this so i figure it may still be a thing)
#
aaronpk yeah i don't remember fixing anything lke that
#
[schmarty] it took me a while to notice that i just wasn't getting stuff from recently added feeds. aperture's laravel.log showed mysterious (to me at the time) 502 gateway errors that i finally figured out were the response from calling my broken-at-the-time watchtower API endpoint.
ShadowKyogre joined the channel
#
[schmarty] sounds like that doesn't ring a bell, so i'll open an Aperture issue. thanks so much!
#
aaronpk 👍
[fluffy], maxwelljoslyn, joshproehl, btrem and Seirdy joined the channel