#dev 2021-10-19

2021-10-19 UTC
gRegor, [benatwork] and jjuran joined the channel
#
aaronpk Weird, suddenly all of Tantek's posts from 2021 appeared in my reader. I don't yet know if this was an issue with my polling schedule or if it was some fetching error that got resolved
amcorrigal and nertzy__ joined the channel
#
capjamesg[d] Jamietanna GWG [tantek] Thanks for sharing everyone. I was not sure about implementing it because there was this very discussion going on in the GitHub Issue. One thing on my mind is that h-x-app (or h-app) may evolve in the future to include more attributes f more consumers pick up the format which is why I think exploring different options like a manifest is interesting. But I feel that is out of scope for an IndieAuth client discovery
jonnybarnes joined the channel
#
capjamesg[d] I think h-x-app is missing an attribute to describe the client. I would propose a p-description attribute (if a GitHub issue is needed, I'll create it 🙂 ). When you authorize an application to access your Twitter account (and this is the case with other providers too) you usually see a brief bio about the project itself. This is determined by the user. I feel like this would be valuable context to display on an IndieAuth server.
#
capjamesg[d] I would likely present this information in its own box in my IndieAuth authorization stage.
#
capjamesg[d] Like this: https://jamesg.blog/assets/GoqEAauth_screen.png
gRegor and gRegorLove_ joined the channel
#
[KevinMarks] I'd suggest (p-)summary is more consistent with other microformats, and leaves content available for a longform version - name/summary/content is a good uniform pattern
#
capjamesg[d] !tell sknebel Ruxton thank you both for encouraging me to explore IndieAuth 🙂
#
Loqi Ok, I'll tell them that when I see them next
#
sknebel :)
#
sknebel I'll need tofind a long weekend somewhere and read through the (what feels like) hundreds of github notifications I got from the repo in the past months :D
hendursa1, kogepan, grantcodes[d], schmudde, gRegorLove_, gRegorLove__, tetov-irc and [calumryan] joined the channel
#
[KevinMarks] Do we have a "disk filled up" antipattern? Because I managed to take a site down by writing too much to a database today.
#
sknebel I'm not sure that counts as a pattern :D
#
Zegnat admintax-lite?
#
Allie [KevinMarks]: underprovisioning disk is a real problem at small scales i think
#
Allie "oh it's a web server how much disk does it really need"
#
Allie "oh lol the system's unrecoverable because 0 bytes available on system"
#
[KevinMarks] The number of times people's sites have gone down because log files filled up disk here too
#
sknebel and at large scales it's literally an admin-tax, on your wallet :D
#
capjamesg[d] 😄
#
sknebel (hm, I don't think my VPS is partitioned in a way that runaway code wouldn't interfere with the core system. I should maybe fix that on the next fresh setup
akevinhuang joined the channel
#
Allie docker's failure to free up disk space has killed many an unaware small VPS
#
capjamesg[d] [fluffy] how do you manage sessions in Publ?
KartikPrabhu joined the channel
#
aaronpk Log files filling up disks has bit me more than once too
#
aaronpk I need to do that trick of keeping a 2gb file on disk that I can delete when I need to recover the system when there's 0 bytes free
schmudde, hendursaga, hs0ucy, hepphepp[d] and ASSISTENZA joined the channel
#
petermolnar just send those pesky logs to the cloud, it never fills up! /s
#
petermolnar joke aside: syslog can be set to rotate logs when they reach a certain size. If you set it up once, and then pipe *everything* through syslog, it won't bite you again.
#
Loqi logrotation has 1 karma over the last year
#
[snarfed] logrotation++
#
[KevinMarks] you do still need to remove the old ones, but yes
jonnybarnes and amcorrigal joined the channel
#
[fluffy] [capjamesg] I use the default flask.session and store the user identity as the only persistent piece of data.
hendursaga joined the channel
#
[fluffy] All other permissions things are derived from that on a per-request basis.
#
[snarfed] [KevinMarks] oh agreed, you definitely want to include garbage collection in log rotation, but most do
#
[tantek] aaronpk, haven't touched my Atom generation code in ages. Were you subscribed to my h-feed?
#
[tantek] folks, modern operating systems themselves suck at handling filled disks
#
aaronpk yes http://tantek.com/
#
Loqi Tantek Çelik
#
[KevinMarks] I remember with Oracle you had to allocate fixed size files for the database to use, so `i suppose filling the disk is the next level of this
#
[tantek] aaronpk, hmm, I didn't change any h-entry date handling code either. and no DST changes
#
aaronpk strange
#
[tantek] only "interesting" thing I did very recently was post a new GitHub issue which I haven't done in a while but I've done that before so it's not new
#
petermolnar > you do still need to remove the old ones, but yes
#
petermolnar no, you don't. My syslog is set to keep 3 rotated and gzipped logs and delete the old automatically.
#
petermolnar the trick is to rotate on size, and not on date
#
petermolnar which is something I still haven't done
jjuran, akevinhuang and gRegor joined the channel
#
[jacky] probably an odd request but do people store cookies in their HTTP clients? like for Webmentions or even Microsub servers?
#
aaronpk no, cookies are for browsers
jonnybarnes joined the channel
#
[fluffy] Back in the days before bearer tokens it was fairly common for HTTP clients to use a cookie jar but yeah bearer tokens make that an antipattern.
#
[fluffy] When did bearer tokens appear on the scene, anyway?
#
[fluffy] oh I guess that’s been there since HTTP 1.0
#
GWG I've only ever used a cookie once
#
GWG In IndieAuth
#
[fluffy] But I don’t remember seeing them actually get used until OAuth got popular
#
capjamesg[d] I use Flask's session.
#
capjamesg[d] I don't know if that sets cookies but I don't think so?
#
[fluffy] [capjamesg] Flask’s session stores it in a cookie
#
capjamesg[d] Oh they are.
#
capjamesg[d] I just Googled it. Thanks [fluffy].
#
[fluffy] The default behavior is to store all the data in a signed cookie, which is trivial to decode but is also tamper-proof
#
capjamesg[d] Well then I have used cookies.
#
capjamesg[d] But only for essential purposes.
#
capjamesg[d] Re your original question [fluffy], I do also wonder when Bearer tokens came around.
#
[fluffy] As a note you should never, ever store anything that you want to keep private from the user in a default Flask session.
#
[fluffy] Which is why in Publ I *only* store the identity, which hopefully the user already knows 🙂
#
[fluffy] (Well, not quite true, during Twitter login it also stores the temporary client credentials in the session but those get revoked as soon as login completes, and the worst that anyone can do with that in the meantime is, uh, post to their own Twitter account)
#
capjamesg[d] I think I store two things: access token, and email address.
#
capjamesg[d] Both things are not sensitive to users. I don't really advertise access tokens on anything but my Micropub server but I also don't think it's a problem if users can get them.
#
[fluffy] Actually that might be the Authl default and I might override that in Publ now anyway? I forget, software is hard
#
[fluffy] I remember changing Publ to using a process-local dict for transitory login data so that I could support PKCS
schmudde joined the channel
#
capjamesg[d] Software is indeed hard.
#
[fluffy] Ah right I changed Authl’s default to use a process-local dict, and Publ no longer overrides that default to use the Flask session.
#
[fluffy] I had previously set Publ to use the Flask session by default to support the load-balanced case by default but then I came to realize that’s kind of bogus and any situation where load balancers are involved, the plug-and-play default isn’t going to be useful anyway.
#
[fluffy] so it’s better to default to safety.
#
capjamesg[d] I assume there's nothing wrong with my approach?
nertzy_ joined the channel
#
capjamesg[d] [KevinMarks] I added p-summary as a property to all of my h-app markup.
#
capjamesg[d] I'll maybe document that idea on the wiki.
#
capjamesg[d] My endpoint consumes it.
#
[KevinMarks] Having a consuming tool does encourage usage
jonnybarnes joined the channel
#
[fluffy] [capjamesg] yeah storing the access token in the session is totally fine. Not too different than the classic pattern of just storing a session ID in the cookie and then associating all the session data with that server-side.
#
capjamesg[d] [KevinMarks] I now support url, name, logo, and summary: https://github.com/capjamesg/jamesg-indieauth/blob/e2e9b23bc302eadc2d8fb42e61aa06cef8c6f892/app.py#L113
#
[tantek] cookies are for user agents, which are usually browsers
#
[tantek] using (e.g. login) cookies with a service on your own website makes sense for accessing things elsewhere
#
[tantek] may also make sense in a world of private posts
#
[tantek] is that an alternative to TicketAuth
#
[tantek] speaking of which, aaronpk, I was going to privately comment about the title of your talk for btconf, but realized it might be worth a broader user-centric (re)framing of OAuth
#
[tantek] context: https://beyondtellerrand.com/events/dusseldorf-2021
#
[tantek] when I consider the "why" of OAuth, especially from a peer to peer perspective (instead of "user vs bigcorp service"), it's about recognizing someone online
#
[tantek] i.e. something like: "Til we meet again online, or, how would we know?"
#
[fluffy] I wouldn’t say cookies are an alternative to TicketAuth so much as a means of providing sorta-auth-tokens to things that don’t support auth tokens.
#
[tantek] yes that's better put
#
[fluffy] TicketAuth is more about the flow of granting a token to something in an unsupervised way.
#
[tantek] so technically one could use server-side / server-sent cookies to implement TicketAuth
#
[fluffy] I’m not sure what you mean by that.
#
[fluffy] TicketAuth is completely orthogonal to cookie-based authentication stuff, as I understand it
#
[fluffy] like I don’t see where cookies would be involved.
#
[tantek] in as much as cookies are used in OAuth based systems today
#
[fluffy] No user agent ever touches anything involved in a TicketAuth flow
#
[fluffy] I mean I suppose that you could have a TicketAuth flow that eventually results in a cookie being added to a browser or something but that feels like a big stretch.
#
[tantek] as noted, servers can keep their own cookie jars
#
[tantek] servers can act as user-agents, e.g. curl
#
[fluffy] OKay sorry I meant ‘browser’ not user-agent
#
aaronpk what is a user agent?
#
Loqi User-agent is a common HTTP header that generally indicates the name, version, and a URL for the application making the request, and is also a robots_txt command (User-agent:) that tells specific robots by name to obey the following commands https://indieweb.org/user-agent
#
aaronpk heh
#
[tantek] and my point is that user-agents in general can use & store cookies
#
[tantek] cookies are not exclusive to browsers
#
[tantek] looking forward to this: "This session explains OAuth through the lens of everyday life, without jargon or code."
#
[fluffy] Sure, but TicketAuth doesn’t result in an HTTP cookie grant, it results in a bearer token grant. The user agent could store that bearer token in ‘a cookie jar’ as a generic concept of a storage mechanism.
#
[tantek] yes
#
[fluffy] But when the token is used it would be sent as a bearer token, not as a cookie.
#
[tantek] aaronpk, I fear your btconf session title may be underselling your talk
#
aaronpk good thing it's a single-track conference then 😂
#
[tantek] the single-track conference is a bit of an illusion. there's always the hallway / coffee-break track
#
aaronpk true
#
[fluffy] or the “falling asleep in the back of the room” track
#
[tantek] if your session is not right after a coffee break, you may be ok, otherwise yes you're competing with "is this in-person conversation I'm having more interesting than this session title?"
#
[tantek] To me, at a highlevel OAuth is solving the problem of "hey we've met before!" on the web
#
[tantek] or rather "have we met before?"
#
[tantek] and then has a bunch of optional stuff attached to that which answers questions like "did I give you permission for this already?"
[schmarty] and kogepan joined the channel
#
capjamesg[d] Could h-x-app not be interchangeable with with h-product?
#
capjamesg[d] h-x-app marks up applications but the properties are currently very similar to h-product.
#
capjamesg[d] I think h-x-app has a place but I think it would require an App Store consumer to really thrive.
jjuran joined the channel
#
gRegor jacky, are the fortress and lwa links here down temporarily? https://indieweb.org/h-x-app#Jacky_Alcine
#
[jacky] ooh yeah that they are
#
[jacky] lemme actually update that
#
[jacky] I cannot b/c I can't sign in with my site (error on my site, not the wiki)
tetov-irc joined the channel
#
[tantek] snarfed, does Bridgy provide backfeed of reacji on GitHub discussions (TIL they're different from issues), e.g. https://github.com/WebWeWant/webwewant.fyi/discussions/191
#
[snarfed] [tantek] sorry no, no discussions support at all right now
#
[snarfed] I don't use them at all, but I'd love to hear from anyone who does, or who investigates them, and can figure out how they'd map to indieweb mf2 etc!
#
[tantek] snarfed, real world example there ^ where the original site already handles webmention backfeed from Bridgy from Twitter!
AaronGustafson joined the channel
#
[tantek] does it make a difference that there are issue redirects? e.g. https://github.com/WebWeWant/webwewant.fyi/issues/131
#
[snarfed] doubt that helps since bridgy uses the API
#
[tantek] sorry I meant https://github.com/WebWeWant/webwewant.fyi/issues/191 for the equivalent
#
[snarfed] thanks for the example! and I see others with comments. still curious about the model, eg are they flat posts with comments, threaded, something else, etc
#
[snarfed] gotta run but feel free to file issues with investigations!
#
[tantek] first cut as treating discussions as issues would be a good start!
#
[tantek] should I file issues explicitly asking for GitHub "discussions" support? similar to "issues" (i.e. for both backfeed and publish?)
#
[tantek] looks like there’s a GraphQL endpoint now: https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions
#
[tantek] (via Aaron Gustafson who's working on the webmention support in webwewant.fyi)
Seirdy and omz13 joined the channel
#
[tantek] who also filed a Bridgy issue! https://github.com/snarfed/bridgy/issues/1077
#
Loqi [aarongustafson] #1077 Add support for GitHub Discussions