#dev 2020-01-16

2020-01-16 UTC
jolvera, [KevinMarks]1, [tantek]1, voxpelli, sfoster, [jgmac1106], TGiske, eindoofus and [KevinMarks] joined the channel
#
eindoofus hi, just wondering how in-demand sass knowledge is these days? i'm going through online courses for html/css and not sure which to chose. i also see flexbox mentioned in one
#
eindoofus i have some backend knowledge but near zero on the frontend, thus the stupid questions
nickodd and [email096] joined the channel
#
[email096] Yay, Edge has MIDI support!
[dmitshur] joined the channel
#
[dmitshur] is beesbuzz.biz here? (not seeing them but given they reported issues in https://github.com/indieweb/indieauth/issues I'm hopeful)
#
[dmitshur] [fluffy] hi!
#
[dmitshur] 👋
[fluffy] joined the channel
#
[fluffy] howdy!
#
[dmitshur] I wanted to share another weird thing I was thinking about re https://github.com/indieweb/indieauth/issues/35 but don't want to derail that issue
#
Loqi [fluffy-critter] #35 Improve validation rules for the verification response 'me'
#
[dmitshur] imagine a user enters https://example.com/ as profile url, an auth endpoint is discovered, IndieAuth authentication flow is successful, and the endpoint returns a "me" value of... a completely different page that is 404 or something.
#
[fluffy] I don’t see that as an issue
#
[fluffy] I mean, as long as it passes all other validation
#
[fluffy] It would be confusing but that’s just like, someone shooting their own foot
#
[dmitshur] it's an odd case for me to consider because I want to discover user's metadata such as h-card.photo, find rel=me links, etc.
#
[fluffy] oh, sure
#
[fluffy] that doesn’t seem like an issue for IndieAuth to care about though
#
[dmitshur] but here's the thing, I want to implement RelMeAuth and use it only when there isn't an authorization endpoint
#
[fluffy] and I’d also love to see IndieAuth be supported just as a plain ol’ federated authentication thing without having to buy into the rest of IndieWeb
#
[dmitshur] so if I discover IndieAuth authz endpoint, I may need to consider one URL as their canonical user profile.
#
[dmitshur] Otherwise I need to consider a very different URL...
#
[fluffy] like the IndieAuth flow itself doesn’t require any parsing or even retrieval of the final profile page, it just needs to honor the URL
#
[dmitshur] so I need to decide what URL to use for RelMeAuth purposes
#
[fluffy] doesn’t RelMeAuth just use the initial URL as the profile? it’s not getting an actual profile URL from whatever final selected auth mechanism there is
#
[fluffy] it just has to verify that the auth mechanism’s profile links back to the initla uRL as rel=“me”
#
[dmitshur] maybe I should just mimic the https://indieauth.spec.indieweb.org/#discovery-by-clients behavior for RelMeAuth too.
#
[fluffy] like the whole concept of having a profile URL that redirects seems sketchy to begin with
#
[dmitshur] yeah
#
[fluffy] I haven’t looked much into the details of RelMeAuth though. There’s probably something I’m not aware of. 🙂
#
[dmitshur] I haven't either yet, it's a TODO
#
[dmitshur] but things would be much simpler if there weren't redirects 😛 or fewer of them
#
[fluffy] Incidentally, regarding indieauth issue 35 I wrote https://github.com/fluffy-critter/AnyAuth and also have https://anyauth.beesbuzz.biz/
#
Loqi [fluffy-critter] AnyAuth: An IndieAuth endpoint that will report whatever identity URL you want
#
[dmitshur] hehe
#
[fluffy] specifically I wrote it to harden the IndieAuth implementation in Authl; it was realizing I wasn’t even doing the basic domain match validation that led me down the path of trying to properly understand the profile redirect specd.
#
[fluffy] *spec
#
[dmitshur] that might come in handy for me later, thanks
#
[fluffy] Authl implements my proposed ‘subdirectory of normalized path’ amendment, incidentally.
#
[dmitshur] yeah, right now I'm just not supporting redirection at all and requiring all URLs to be equal, with a "TODO: add support for advanced redirection"... and working on resolving the TODO.
#
[fluffy] yeah that’s completely sensible
#
[dmitshur] well, cheers, thanks for looking at this stuff too and sharing your findings 🙂
#
[fluffy] in my experience, most OpenID implementations just do that, which is annoying. Not that OpenID is what should be mimicked in general, but like, there’s precedent.
#
[dmitshur] what exactly is annoying? What OpenID impls do, or that IndieAuth differs?
#
[fluffy] what OpenID impls do
#
[fluffy] strict URL matching
#
[dmitshur] I see.
#
[fluffy] IndieAuth as a spec swings too far in the other direction by assuming that the domain is the unit of trust, rather than the URL. Which is of course what I wanted to address with 35.
#
[fluffy] I don’t know what the OpenID spec says, incidentally, and I’ve seen different implementations do different things.
#
[fluffy] I just remember being supremely annoyed by how one forum I was on didn’t see http://example.com/me and http://example.com/me/ as equivalent.
#
[dmitshur] hah. see https://chat.indieweb.org/dev/2020-01-11/1578727991845900
#
Loqi [[dmitshur]] On a different but related note, "https://example.com/user" and "https://example.com/user/" are technically different URLs. It seems weird to let 2 completely different people differ only by a trailing slash. But https://indieauth.spec.indieweb.org/#...
#
[fluffy] yeah, it’s kind of a mess no matter how you look at it
#
[fluffy] The “more specific URL” proposal is a compromise
#
[fluffy] and this has always been a thing that confuses people going all the way back to the earliest days of the web; people wondering why they were getting a redirect to add a / to a folder’s URL, “the browser should just know it’s a directory”
#
[fluffy] but then like, if the redirect doesn’t happen, then relative links/paths don’t work
#
[dmitshur] I will say, as I understand the spirit and target audience of IndieAuth, I am okay with the domain being a unit of trust, especially if that buys simplicity. I wouldn't want IndieAuth to try to solve the thousands-of-users per domain problem, because that'd likely make it much more complicated... but I understand other people may have different priorities or preferences and that's valid.
#
[dmitshur] and if two users want to troll and have URLs that differ only by a trailing slash, that's their choice and great. if a single user wants to be able to enter their URL with a trailing slash or without, and have the authz endpoint return a canonical version, that's great too.
#
[fluffy] I want to see wider adoption of a completely open federated identity protocol.
#
[fluffy] I want IndieAuth to be adopted by Mastodon.
#
[fluffy] and I want IndieAuth to be trustable and not violate user expectations.
#
[dmitshur] I'm in agreement on not violating expectations.
#
aaronpk The domain as the origin of trust is not new to IndieAuth, there's precedent there in things like CORS, DNS, etc
#
[fluffy] and I also want to see it gain wider adoption on things where it isn’t a single-stack whole-domain thing. Like tilde.club.
#
aaronpk like if your email is @example.com then whoever maintains that DNS controls where your email goes
#
[dmitshur] my top goals are to let more people use URLs as identifiers, and to let people sign in to my site even if github is down. if you're curious, what I'm working on is https://github.com/shurcooL/home/issues/34.
#
Loqi [dmitshur] #34 add support for signing in via IndieAuth
#
aaronpk so i think it's fair that it's the same for IndieAuth
#
[fluffy] the power to IndieAuth, to me, is people being able to specify their own endpoint, but if people can specify, say, anyauth.beesbuzz.biz as their endpoint because they’re on tilde.club, then that means anyone can trust them with any tilde.club identity.
#
[fluffy] and to me that’s the problem I’m trying to solve with that proposal.
#
aaronpk I'm not following
#
[fluffy] okay so like
#
[fluffy] user has a webpage on tilde.club. Say, https://tilde.club/~alice/
#
[fluffy] tilde.club lets you host whatever arbitrary HTML you want. They own that directory, they can put whatever arbitrary stuff they want in their HTML.
#
[fluffy] let’s say tilde.club/~alice sets their profile as an IndieAuth endpoint that provides a “me” URL of https://tilde.club/~bob/
#
[fluffy] Alice has no control over Bob’s website, but by having their own IndieAuth endpoint they can still appear to be Bob.
#
aaronpk oh is that what you mean by the "more specific" url?
#
[fluffy] Because Alice’s IndieAuth endpoint is assumed to be authoritative for all of tilde.club.
#
[fluffy] yeah
#
aaronpk so the intent of that mechanism is to let people on tilde.club type in "tilde.club" into a sign-in box, and then their actual profile url is sent to the app
#
aaronpk i don't think there's a case where we'd actually want it to work in reverse
#
[fluffy] yeah but tilde.club doesn’t work that way. it isn’t a specific social platform like Mastodon or microblog or whatever
#
aaronpk sure i was just using that example
#
[fluffy] it’s like the good old days of having www.example.edu/~somebody
#
aaronpk also it could because they have user accounts and they could implement IndieAuth on their api
#
aaronpk but anyway that's not the point here
#
[fluffy] right
#
aaronpk I'm trying to think of a case where we actually want someone to be able to start in a sign-in form with a "more specific" url, and I'm not thinking of any
#
[fluffy] my point is that I want people to be able to safely participate in use of IndieAuth without necessarily needing to own their own domain. I like using tilde.club as an example for this because it represents a lot of this sort of thing to me.
#
aaronpk I think micro.blog works this way already too
#
[fluffy] don’t micro.blog identities use subdomains though?
#
[fluffy] I thought subdomains weren’t allowed
#
aaronpk Nevermind I am wrong
#
aaronpk what do you mean not allowed?
#
[fluffy] like having micro.blog provide fluffy.micro.blog as the final “me” URL
#
[fluffy] I thought the domain had to match exactly
#
aaronpk indieauth doesn't treat subdomains specially, they're treated as separate domains
#
[fluffy] yeah that’s what I meant
#
aaronpk mostly because it's basically impossible to know what actually is a subdomain
#
[fluffy] yeah
#
aaronpk thanks to things like .co.uk
#
[fluffy] I mean you could do the whole “more specific” rule for that too but it’s still a paaaaain
#
aaronpk yea
#
[dmitshur] so the high level problem is when example.com has no idea what IndieAuth is, but lets certain people control certain pages. then, if a user has full control over example.com/foo/ but no control over example.com or any other pages, they can still control the entire example.com domain. is that right?
#
[fluffy] [dmitshur] yeah
#
[fluffy] “control” probably isn’t the right word for it but it’s close enough.
#
[dmitshur] yep. in the context of being able to authenticate via IndieAuth.
#
[fluffy] yeah. control as short for “appear authoritatively as” in this case
#
[fluffy] or something like that
#
[dmitshur] this reminds me of how the Go project deals with this problem for custom import paths.
#
[dmitshur] on https://golang.org/cmd/go/#hdr-Remote_import_paths:
#
[dmitshur] > The import-prefix is the import path corresponding to the repository root. It must be a prefix or an exact match of the package being fetched with "go get". If it's not an exact match, another http request is made at the prefix to verify the <meta> tags match.
#
[dmitshur] should be easier to understand by looking at the comment at https://github.com/golang/go/blob/f77e7ed7e374311e684fe810bf1aabaf18965a8a/src/cmd/go/internal/get/vcs.go#L825-L830
#
[dmitshur] applied to IndieAuth, it could mean something like... if authz endpoint returns a "me" URL where the original user profile URL isn't a prefix of it, then it should be confirmed that the returned "me" URL specifies the same authorization endpoint URL.
#
[dmitshur] so if tilde.club/~bob uses the authorization endpoint evil.com/auth that returns a "me" value of "tilde.club/~alice", then we check and see tilde.club/~alice doesn't have the same authorization endpoint evil.com/auth, so we can't trust bob.
#
[dmitshur] and I think the prefix rule can be simplified to just inequality. if the returned "me" value is different, then it should be confirmed that if used for authorization discovery, it reports the same authz endpoint.
#
[dmitshur] for authorization endpoint* discovery
#
[dmitshur] I don't know how others feel about this idea, but I'm liking it so far, and I may make it a proposal (if no one else beats me to doing that).
#
[fluffy] Hm, that seems like it’d require even more processing on the consumer’s part
#
[fluffy] since now it has to actually fetch the profile page and make a decision based on that
#
[dmitshur] by consumer, do you mean IndieAuth client?
#
[fluffy] I mean the site being logged into
#
[fluffy] so yeah client
#
[dmitshur] I see two scenarios. either the authz endpoint returns the same URL as what the user entered. in that case nothing more needs to be done.
#
[dmitshur] the second scenario is that the authz endpoint returns a different URL. then the client must do a second "discover the authorization endpoint" call on a different URL.
#
[fluffy] yeah and I don’t like that
#
[dmitshur] it's just running the same code on 2 URLs instead of 1.
#
[dmitshur] it seems conceptually simple to me. what makes you not like it?
#
[fluffy] The fact it’s having to make another URL fetch.
#
[fluffy] also it’s another moving part that could get messed up.
#
[fluffy] It just feels unnecessary to me and I like to elide unnecessary things.
#
[dmitshur] I see, thanks
#
[fluffy] and it adds more complexity. Not a *lot* of complexity, but still, complexity.
#
[dmitshur] I'll think about it more before I do anything, of course.
#
[dmitshur] I agree it adds complexity, but it seems justified for the problem it's solving. but if there's a simpler solution, that'd be better.
#
[fluffy] I like limiting the number of handshake steps, is what it comes down to.
#
[dmitshur] I might be biased but I find the ability of the authz endpoint to return a non-200-OK URL quite unpleasant, and this change would make that scenario impossible as a byproduct.
#
[fluffy] yeah, and I see that as a non-issue personally 🙂
#
[dmitshur] you can still have 1 handshake if you enter your canonical profile URL into the sign in form.
#
[fluffy] (not going to rehash the conversation of course, I see your point of view on it)
#
[fluffy] and I mean I don’t feel *strongly* about this
#
[fluffy] just voicing my kneejerk reaction 🙂
#
[dmitshur] I appreciate feedback 🙂
#
[fluffy] the only thing I feel strongly about with this is that a URL on a domain should not be assumed to be authoritative for the whole domain.
#
[dmitshur] but instead it should be assumed to be authoritative over that URL itself, and all deeper paths, is that what you mean?
#
[fluffy] the first part, definitely, the second part is just the compromise I put in for the “canonical profile URL” case that Aaron brought up
#
[dmitshur] gotcha.
#
[fluffy] “deeper paths” was just a proposed way of addressing that use case.
#
[fluffy] honestly I’d be totally fine with the URL needing to match perfectly, aside from the fact it does cause some UX hairiness sometimes.
#
[fluffy] and also doesn’t allow for the whole “sign in to [foo] and get authorized as [foo/bar]” case
#
[fluffy] like let’s say mastodon grows indieauth support… people should be able to log in using their instance name, rather than their full profile URL.
#
[dmitshur] I think that's a valid concern but I'm not sure if I believe it's best for it to be in scope of IndieAuth. but I haven't made up my mind about these things yet.
#
[fluffy] that’s basically what I do for mastodon auth in Authl (and also twitter auth for that matter) - it doesn’t actually care about the full profile URL, it just cares enough to determine whether it can use the mastodon oauth flow.
#
[fluffy] and for what it’s worth I know my attitude is a bit different than a lot of the IndieWeb folks who feel that people should properly own their entire web presence, including the domain.
#
[fluffy] My intent isn’t that people have ownership of everything, just that they be able to use whatever identity they want.
#
[fluffy] I wrote Authl so that I could better manage that use case and make that possibility available to others (at least ones using Python)
#
[fluffy] like my use case was being able to grant friends protected access to private blog entries, without needing them to set up their own dang website to do so.
#
[fluffy] I haven’t checked my metrics in a while but last I checked, I think something like 60% of logins were via Mastodon, 25% via email, and most of the rest via Twitter.
#
[fluffy] note the lack of IndieAuth 🙂
#
[fluffy] there are a couple of people who do use IndieAuth to login to my site but they’re the distinct minority.
#
[dmitshur] I think that's fair. you have certain use cases in mind and desire to enable/support, and you're done work in that direction.
#
[dmitshur] it comes down to trade-offs of having more specialized, simpler protocols, but more of them... vs fewer but more complicated.
#
[fluffy] I don’t retain access logs for very long but I can definitely speak authoritatively based on who’s requested access via whatever mechanisms and that’s at least a reasonable proxy
#
[fluffy] so in my authorized users list: I have 27 people on my ‘friends’ list. 6 are email, 2 are twitter, and 1 has both twitter and email. The rest are Mastodon.
#
[fluffy] my ‘followers’ list (i.e. people who I share some stuff with but not everything) is 10 people. 1 email, 2 twitter, 1 IndieAuth, everyone else Mastodon.
#
[dmitshur] yeah, the bar to implement one's own IndieAuth authz endpoint is quite high now, so I'm not surprised it's used by very few people. even using another server's existing authz endpoint is still non-trivial.
#
[fluffy] there is of course a lot of selection bias in that mastodon is also where I mostly talk to folks in the first place
#
[fluffy] and yeah I use SelfAuth for mine
#
[fluffy] it’s not great but it was easy to get working
#
[fluffy] I also really wish AutoAuth were more of a thing. It’s very much stuck in the chicken-egg valley right now.
#
[fluffy] one of my December goals was to finish AutoAuth support for Publ but I lost steam pretty quickly just because there was so much to do and so little gain to be had from it.
#
[dmitshur] I'm learning of new projects today 🙂
#
[fluffy] tl;dr, Publ is what I run my site with, Authl is its authentication layer, AutoAuth is an s2s extension to IndieAuth.
#
[dmitshur] I think my second-discovery-on-me-mismatch idea above should be compatible with vast majority of existing IndieAuth implementations, so I have the option of attempting to prototype it and learn from the experience before making any proposals.
[tantek] joined the channel
#
[fluffy] Publ supports IndieAuth c2s but not s2s. (This part is directly in Publ; IMO it doesn’t belong in Authl for Reasons not worth rambling about right now.)
#
[fluffy] and by “supports” I mean like… the c2s flow works, but there’s nothing practical to do with it yet. *eventually* I will add Micropub support which will use it, but… meeehhhhhh
#
[dmitshur] I have to take off soon. thanks for the discussion!
#
[fluffy] I have too many projects 🙂
#
[fluffy] sure!
#
[dmitshur] it was nice to meet you today 🙂
#
[fluffy] same!
#
[fluffy] (also part of the s2s flow is supported, in that it’ll emit Www-Authorization headers for pages where authentication upgrades are a thing. it just doesn’t support the actual login flow yet.)
#
[fluffy] or whatever the correct header is
[fluffy], [tantek], [dmitshur]1 and [email096]1 joined the channel
#
[fluffy] … well it should be anyway. doesn’t seem like it is for some reason.
#
[fluffy] I might have micro-optimized it out again, oops 🙂
#
[fluffy] no it’s sending WWW-Authenticate, phew
#
[fluffy] firefox just wasn’t showing it for some reason
KartikPrabhu joined the channel
#
@jeremyfelt Webmentions work log 20200115 https://jeremyfelt.com/2020/01/15/webmentions-work-log-20200115/ (twitter.com/_/status/1217698234828591104)
dietricha, shakeel, kitt, jmac, myfreeweb, jolvera, mattl, danyao, gRegorLove, voxpelli, superjen96, jeneliza_, TGiske, sfoster, ludovicchabant, willnorris, jimpick, jenelizabeth, [Marlin_Forbes], swentel, simons, gxt, KartikPrabhu, [Rose] and [KevinMarks] joined the channel; nickodd left the channel
#
[KevinMarks] there is a case for profile URLs redirecting, especially with a 301 - think of the rel-me auth case where pointed-to profiles may move.
#
[KevinMarks] a key one was where (eg) profiles.google.com/kevinmarks would redirect to the G+ profile (all of this is now broken, of course)
rainw6ter, simons, TGiske, jjuran and [tantek] joined the channel
#
[tantek] I'm seeing a site down message here, anyone else? https://foursquare.com/v/muni-stop-id-14618-fillmore--haight-outbound-22/52310eea11d2cb66d5de5427
#
[tantek] "Sorry! We're having technical difficulties. Check status.foursquare.com for the latest."
#
[tantek] and nothing about downtime on their status page
[Marlin_Forbes] joined the channel
#
[Marlin_Forbes] yeah gonna timeout
#
[Marlin_Forbes] yup, just got a varnish error page
#
[Marlin_Forbes] classy
#
[tantek] huh, I wonder what it takes for their automated systems to note / report an outage
#
[Marlin_Forbes] the error page renderer is also down
#
[tantek] wow
#
[Marlin_Forbes] probably a CPT POP cached the wrong page for 503
#
[Marlin_Forbes] CPT = Cape Town
#
[Marlin_Forbes] CDN issue probable, this says it's up https://downforeveryoneorjustme.com/foursquare.com
#
[Marlin_Forbes] unless there's some special backend service required to render that specific page, possible
#
[tantek] right, the logged out home page is likely dependent on fewer backend services
simons joined the channel; gimochiDiscord[m left the channel
#
[tantek] And it's back for me (that venue permalink)
ci_trex joined the channel; ci_trex left the channel
#
[tantek] Welcome [Jeremy_Keith]++
#
Loqi [Jeremy_Keith] has 1 karma over the last year
#
aaronpk [KevinMarks]: google is not a shining example here
[KevinMarks] joined the channel
#
[KevinMarks] well no, not any more. Google profiles was a good rel-me provider from 2008 to 2016, through the G+ transition, but then as G+ got neglected they broke it
#
aaronpk Nah it was always a mess of redirects and uncertainty of what is the canonical profile URL for someone
[jgmac1106], simons, jgmac1106, [Rose], glgac, CyOp0x00Discord[, [fluffy], [tantek] and [snarfed] joined the channel
#
[snarfed] i'm seeing more and more sites regularly reattempt bridgy publishing many or all of their posts, all at once. probably static sites that use bridgy publish links and auto (re)send webmentions on every build. not a problem, but getting to be a more notable source of load, esp some sites that post many times a day and have well over >10k posts total
#
aaronpk ouch
#
aaronpk i should check the telegraph logs, i suspect i'll see a similar thing there
#
Loqi +1
#
[snarfed] they're generally all 400s, and normally it'd be easy to short circuit that response, except bridgy publish supports 410 delete, so i have to request each page, follow redirects, look up in the db to see if i've already published that final url, and then also check that it isn't a 410. so they're not cheap
#
[snarfed] (jamietanna your site is one of the more noticeable ones ^, just fyi)
#
[tantek] snarfed, I wonder if there is any pattern in which tools / libraries / services are being used for this
#
[snarfed] yup, the static site rebuild pattern i mentioned above ^
#
[tantek] I meant specific SSG or specific services for SSGs
#
[snarfed] unrelated, [srushe] has been reattempting bridgy publish for https://deeden.co.uk/reposts/2020/01/16/134744 once a minute for a while now. [srushe] you might want to add a limit to the number of times you retry webmentions 😆
#
[tantek] like is it mostly coming from Netlify? (just a random guess)
[srushe] joined the channel
#
[srushe] Oops. On it
#
[snarfed] i expect the pattern of resending webmentions for all pages on every rebuild is somewhat common for SSGs that support them. i don't know any details though
#
[tantek] I definitely conservatively coded my Webmention sending, literally only tied to a user action (clicking "Publish" which really means "syndicate" right now for me, I "publish" with scp in terms of stuff showing up on my home page, feed file, permalinks).
#
[tantek] I wonder if that kind of defensive coding of Webmention sending is worth documenting as an approach?
#
[tantek] snarfed, makes sense. I suppose if an SSG could detect that it didn't need to send a webmention for a page, then it could detect that that page didn't need regenerating
#
[tantek] and SSGs have incentive to reduce non-impact page builds for their own user performance reasons
#
[snarfed] right
#
[snarfed] looks like jamietanna's bridgy publish wms are going through telegraph based on client IP, but that doesn't mean much
#
aaronpk this is a classic problem with SSGs, they don't know what pages changed so they rebuild everything
#
aaronpk i think hugo is supposed to be smarter about that? but jekyll is a classic problem
#
[snarfed] (speaking of which, hope he's ok, i'd love to keep going on https://github.com/snarfed/bridgy/pull/906 !)
#
Loqi [jamietanna] #906 WIP: Meetup.com
#
[tantek] aaronpk, I feel like SSGs could at least do a blankspace normalized diff and then abort a page update
#
aaronpk go file an issue on jekyll ;-)
#
[tantek] lol
#
[tantek] if I was using a specific SSG myself, I would 🙂
KirushikDiscord[ and [schmarty] joined the channel
#
[schmarty] i don't think any SSG actually supports sending WMs?
#
aaronpk no but it's about telling the webmention sender which pages changed
#
[schmarty] but an SSG building/hosting platform like Netlify could
#
[schmarty] right. i built that into my site builder very early
#
[tantek] documenting those approaches / methodologies would be very useful!
#
jamietanna[m] Snarfed I am! It's been super busy here unfortunately and I'm on holiday (without laptop) next week so won't be back to bridgy work until following week unfortunately
#
[tantek] maybe on the /SSG page
#
jamietanna[m] I have a sitemap that I generate (and use to list what should get wm'd) - I could use that and see the `lastmod` for what I need to send, reducing what is outgoing even more
#
[tantek] yes that kind of thing!
#
[snarfed] jamietanna ah right! forgot you were still out on holiday. please disregard, no hurry. enjoy!
#
jamietanna[m] Oh no I'm not yet on holiday! Just been too busy unfortunately - I'd love to get it finished too
#
[snarfed] lol ok. np!
#
jamietanna[m] Sorry snarfed is that for the meetup bridgy ones? Or ie ones I've already got syndicated?
#
jamietanna[m] > (jamietanna your site is one of the more noticeable ones ^, just fyi)
#
jamietanna[m] That question in response to this
#
[snarfed] already syndicated ones
#
[snarfed] and again, totally not a problem on bridgy's end, fine to leave it like that, it was just an interesting pattern to notice
#
[snarfed] each bridgy publish wm is generally 1-2s due to the work it has to do (described above), so your lastmod fix would probably speed up your rebuilds a decent amount
#
jamietanna[m] Oh interesting. I think they shouldn't be attempting to resend so that isn't great. I can look into it
#
[tantek] ah that should be something fixable by checking for an existing syndication link to a destination before attempting to syndicate to it!
#
[tantek] that could even be a Selector
#
[snarfed] a bit more nuanced than that, you still want to send wms if the post is updated or deleted
#
[snarfed] the simple crude default of resending all wms is totally reasonable, just inefficient
#
[tantek] no for syndication
#
[tantek] no service does syndication updates right? not Bridgy at least
#
[snarfed] sure for syndication, bridgy publish supports updates and deletes on some silos
#
[tantek] oh
#
[snarfed] ah sorry, deletes, not updates
#
[snarfed] although actually no i think there are some kinds of updates that work, eg adding labels or tags
#
[snarfed] https://brid.gy/about#publish-types
#
[snarfed] anyway
#
[tantek] hmm, looking into deletes
#
[tantek] ah, the trick is that deleted post permalinks DO NOT have a syndication link either! so this technique still works
#
[snarfed] also there are other synd services, so ideally we don't want people to enshrine bridgy's specific support (or lack) as the general guidance for when to send synd wms
#
[tantek] e.g.
#
[tantek] pseudo-code: if !(.u-syndication[href^="https://twitter.com"]) then output Bridgy Syndicate To Twitter Link
#
[snarfed] hmm the site still needs to know to send a wm to bridgy publish on deletes though
#
[tantek] sure, that's a separate code path anyway
#
[tantek] point being, this would stop the dupe Bridgy publish webmentions in the common case
#
[snarfed] eh not if you leave the synd link in the content even for 410 deleted responses
#
[tantek] that makes no sense
#
[tantek] why would you link to the POSSE copy of something you deleted?!?
#
[tantek] presumably you deleted it because you didn't want it visible
#
[tantek] so linking to a visible version somewhere else makes zero sense
#
[snarfed] heh sure, i wasn't on-the-fly-designing the user visible page, just the plumbing for syndicating the delete
#
[snarfed] the synd links could be invisible, the whole 410 response could be invisible, 🤷
#
[tantek] invisible begs a lot of people to view source
#
[snarfed] yup i know our stance on that
#
[tantek] yeah I haven't built delete propagation so I'll re-assess when implemented
#
@bmann ↩️ Has anyone bugged y'all about using the WP Webmentions plugin https://wordpress.org/plugins/webmention/ along with Bridgy? https://brid.gy/about Totally different implementation, but would mean Twitter (and other networks!) would get sucked right into the AVC website. (twitter.com/_/status/1217868832959844354)
#
@bmann ↩️ Has anyone bugged y'all about using the WP Webmentions plugin https://wordpress.org/plugins/webmention/ along with Bridgy? https://brid.gy/about Totally different implementation, but would mean Twitter (and other networks!) would get sucked right into the AVC website. (twitter.com/_/status/1217868832959844354)
#
[tantek] oh boy
#
[snarfed] we're just comparing the very simple approaches of a tradeoff btw not-ideal markup (eg synd links on deleted posts) vs special case code for synd services
#
[snarfed] anyway
eli_oat joined the channel
#
[tantek] part of it is that I want to avoid unintended additional webmentions to Bridgy
[generativist] joined the channel
#
[tantek] since *anyone* can come crawl your site and send webmentions to all the links there
#
[tantek] so it's better defensive coding to *not* have the bridgy publish links if you've already bridgy published
#
[snarfed] aww thanks, that's nice, but honestly low priority. minimizing wms is a nice optimization but seems lower priority than correctness and functionality
#
[tantek] if it's a pattern we can encourage then we can reduce the long term redundant/useless traffic to bridgy
#
[snarfed] it's on bridgy publish to handle all of this correctly no matter when/how it gets wms
#
[snarfed] i guess, sure. just, very low priority
#
[tantek] sure, defensive coding vs. a bit more infrastructure headroom
petermolnar joined the channel
#
[tantek] I'm saying as a "considerate bridgy user" we should use bridgy efficiently, not sloppily (even though Bridgy is defensively coded to handle it)
#
[tantek] especially as a *volunteer* service
#
[tantek] I believe that places a different social responsibility context around it
#
[tantek] One way to "pay" or "donate" to Bridgy is with your own time coding conservatively with your use of a common resource
#
[snarfed] agreed! great courtesy. and as the service owner, right now i'd personally prefer that we prioritize ease of implementation and adoption, since the additional incremental load is small and doesn't cost anything
#
[snarfed] but we're basically in violent agreement 😁
#
[tantek] seeing if I can code this up before I document it as a how to 🙂
#
jamietanna[m] Agreed! Snarfed if you're able to share some URLs I've tried to re-syndicate in the past few weeks I can look at investigating what's gone wrong with my webmention sending 👍🏽
#
[snarfed] jamietanna sure! recent example ended at 10:13am PST yesterday. last three URLs were https://www.jvt.me/mf2/2019/12/yudga/ , https://www.jvt.me/mf2/2019/12/0nbqa/ , https://www.jvt.me/mf2/2019/12/isqba/
#
Loqi [Jamie Tanna] This post has been published by my Micropub endpoint (code in https://gitlab.com/jamietanna/www-api ) and syndicated to Twitter via https://brid.gy 🙌 #IndieWeb - I'm able to own my tweets from my personal website at https://www.jvt.me and you can ...
#
jamietanna[m] Thanks snarfed, I'll look into them!
#
jamietanna[m] I have a feeling it will be that it didn't get written to the DB properly (sqlite Java library has an issue with locking)
gRegorLove joined the channel
#
[tantek] huh there's no Brainstorming section on /Bridgy
[KevinMarks] joined the channel
#
[tantek] I'm going to call links like https://brid.gy/publish/twitter "command links" as they're links for essentially performing a command
#
[tantek] is trying resist coining "commandmentions"
#
[tantek] or "callmentions" - Webmentions that perform an API call
#
aaronpk stahp 😂
#
[snarfed] i kinda regret overloading webmentions for that. not sure if we want to encourage it or draw any more attention to it
[mykola_bilokons joined the channel
#
[generativist] Greetings, everyone. After talking with [tantek], I realized I should introduce what I'm working on right now. I mentioned before, but -- like a lot of python-favoring data scientists -- I spend most days inside collections of Jupyter/Ipython notebooks. Previously, I've had ad-hoc collections of scripts to make webpages out of them. And, my entire dissertation was a large collection of notebooks converted to PDF. So right now, I'm turning
#
[generativist] it into an indieweb-favoring command line tool.
#
[generativist] E.g. (roughly)
#
[generativist] `$ falsifiable init # creates project`
#
[generativist] `$ falsifiable build # converts all notebooks and creates directory indices`
#
[generativist] `$ falsifiable publish # extensible if you're not just doing git`
#
[generativist] Mostly, I want this. But, I also think a lot of people who follow me on twitter in general and data scientists in particular are technically competent and recognize the value in owning your domain -- so this is a low friction onboarding thing.
#
[tantek] snarfed, uh, :genie: 🍾
#
@JoshuaGilless webmentions as a service (twitter.com/_/status/1217881819707625472)
#
[tantek] alright, documented my brainstorm before implementing so I don't feel like I have to neglect everything else just to code this today: https://indieweb.org/Bridgy#Minimize_Publish_Rerequests
tsrt^ and KartikPrabhu joined the channel
#
@_carlbrand Testing Webmentions https://carlbrand.dev/2-testing-webmentions (twitter.com/_/status/1217916132885237762)
#
@jezcope In which I rip out Disqus in favour of something decentralised and free (as in speech): https://erambler.co.uk/blog/replacing-comments-with-webmentions/ (twitter.com/_/status/1217917686199586816)
coryschwartzDisc, gRegorLove_ and TGiske joined the channel
#
@vform Replacing comments with webmentions | eRambler - https://erambler.co.uk/blog/replacing-comments-with-webmentions/ (twitter.com/_/status/1217930294164107266)
[tantek] and [manton] joined the channel