#dev 2022-08-02

2022-08-02 UTC
#
gRegor capjamesg, camendesign.com has ReMarkable versions of posts, linked from the footer, e.g. http://camendesign.com/blog/rogues-dice and http://camendesign.com/blog/rogues-dice.rem
[timothy_chambe], gRegorLove_, gxt___, jjuran and tetov-irc joined the channel
#
sknebel !tell veracioux not sure about out-of-the-box things, but the usual email stacks generally can query databases for user information, so you could set that up e.g. around postfix and dovecot
#
Loqi Ok, I'll tell them that when I see them next
[tonz] joined the channel
#
@drei4u Decentralized comments for blogs etc. This is my webmention page. Sadly it did not flourish. I still like though. https://oliodigest.com/replies/ (twitter.com/_/status/1554453562662735872)
gRegorLove_, AramZS, gRegorLove__, jacky and angelo joined the channel
#
@Kdecherf ↩️ About that part, did you check things around IndieWeb like POSSE principle and/or webmention? https://indieweb.org/ https://indieweb.org/POSSE https://indieweb.org/Webmention (twitter.com/_/status/1554507808393121794)
#
[KevinMarks] This is interesting https://twitter.com/AanandPrasad/status/1554498869261656064?t=YZaj7Mx78DK0JIWz0E3F3g&s=19
#
@AanandPrasad @simonw I think @bfirsh showed me this – it produces *recordings* of terminal sessions using SVG + CSS animations https://github.com/nbedos/termtosvg (twitter.com/_/status/1554498869261656064)
#
@kevinmarks ↩️ You use http://brid.gy to connect it to other social network responses (though not from Facebook as Meta ended interop) (twitter.com/_/status/1554511654003638273)
gRegorLove__ and jacky joined the channel
#
@schnarfed ↩️ We do Facebook (and Instagram) with a browser extension now! Scraping is a tar pit, as always, but it's working. https://brid.gy/about#browser-extension (twitter.com/_/status/1554547562333343744)
#
IWDiscordGateway <capjamesg> I just fixed hundreds of broken links on my site.
#
[KevinMarks] [snarfed] OP there is a Meta employee
#
[snarfed] 😆 😢
Steve[m]123, jacky, geoffo and jacky_ joined the channel
#
@jamesvandyne ↩️ We're hiring at Octopus Energy/Kraken Tech. It's a great place to work with a great decarbonization mission. Happy to answer any questions via DM/Email/Webmention :-) https://jobs.lever.co/octoenergy?location=Houston%2C%20TX (twitter.com/_/status/1554571565538283520)
j12t and Ruxton_ joined the channel
#
[tantek] petermolnar++ (pmlnr) has some interesting ideas in #ind for making HTTP more resilient for "sometimes offline" servers
#
Loqi petermolnar has 10 karma in this channel over the last year (43 in all channels)
#
[tantek] e.g. https://chat.indieweb.org/2022-08-02#t1659474073417300
#
Loqi [pmlnr] But what it could be is, for example, a DNS TXT record that indicates the site might sometimes temporary go offline. Thoughts?
#
[tantek] I'm curious if there's been prior work here like in IETF. I'm not even sure how to search for that. Maybe aaronpk would know
#
aaronpk interesting, i'm not sure where that would fall exactly, but i suppose maybe the http group?
#
aaronpk lots of active worok going on there right now https://datatracker.ietf.org/wg/httpbis/documents/
#
aaronpk sort of related: https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc7838bis/
#
[snarfed] the goal is an indication that clients should retry their HTTP requests later? eg, for sending webmentions? seems like we should probably encourage that as best practice regardless. for example, Bridgy retries sending wms for 24h before it gives up, without needing an "intermittently online" signal like this
#
sknebel hm, cant think of anything DNS wise,I think thats usually a protocol level thing (like it is in SMTP)
#
sknebel one could arge HTTP goes in that direction with cache-control rules, that e.g. declare how long since last update cached pages are fine to show
#
sknebel (not the same thing, but related space)
#
aaronpk i guess it would be a way to indicate the difference between the site being unintentionally offline vs intentionally offline
#
aaronpk right now a browser shows a pretty ugly/generic error if it can't connect to the server
#
aaronpk "example.com refused to connect." in chrome for example
#
[snarfed] right, but in general, we probably want to retry similarly in both cases, at least for a while
#
aaronpk is there a difference for a webmention sender between the two?
#
aaronpk i think a webmention sender would be more interested in knowing for sure that it could give up trying, which isn't the case with either type of failure
#
[snarfed] right, we're agreeing. seems like a conclusion here is just to encourage retries, and not worry so much about servers signalling somehow that they're intermittently available
#
aaronpk yeah i was trying to come up with a use case for that signal
#
aaronpk and I do think better error messages presented to a user in a browser would be one
#
[snarfed] true!
tetov-irc, IWSlackGateway4 and [jgmac1106] joined the channel
#
[tantek] yes, use-cases for directly & indirectly for the user.
#
[tantek] directly for better error messages (potentially even prompting the user to have the browser retry asynchronously and notify when it loads.
#
[tantek] indirectly for a better (more realtime, more robust) federated commenting experience, via more precise retrying of webmentions
#
[tantek] there's also maybe an opportunity to solve this in a separate spec that's like the inverse of WebSub, like having a hub that explicitly receives webmentions on your behalf instead of having to receive them all directly
#
aaronpk i mean that exists, but the trick is advertising the webmention endpoint on a site that is down
#
aaronpk so.. webmention endpoint discovery via DNS :P
#
[tantek] yeah, I think the question here is what can we learn from the prior art of SMTP & retrying, and presumably *someone* at some point must have brainstormed HTTP retries in the development of HTTP and written something down.
#
[tantek] it's too obvious of a feature request to not have been previously considered (and if so, why was it rejected)
#
aaronpk oh hey https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After
#
aaronpk https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After#dealing_with_scheduled_downtime
#
aaronpk "Example: Dealing with scheduled downtime"
#
aaronpk defined most recently in RFC9110 https://www.rfc-editor.org/rfc/rfc9110.html#name-retry-after
#
aaronpk but, that only works if the http server is up of course
#
AramZ-S[m] Could be handled by a configuration of an external hash?
#
AramZ-S[m] *cash
#
AramZ-S[m] *cache
#
aaronpk the question is how to do this when the web server is actually offline, assuming there isn't also a proxy server in front of it
#
aaronpk (see the beginning of pmlnr's thread linked above, which starts with the assumption that the http server would be actually powered off for some time)
#
[tantek] right, the "not always on / connected" server is the use-case here, e.g. your webserver being physically on your person and disconnected for hours or maybe days at a time depending on where you are in the world / in transit
nertzy joined the channel
#
[tantek] related use-case, you and the server you're trying to connect to are *both* disconnected from the broader "internet" (i.e. DNS lookup) but you've interacted before/recently (e.g. have certs from requests/responses) *and* you’re both on a LAN (or maybe even directly within bluetooth range) and want to keep talking to each other
#
[tantek] this is the roadtrip/hiking/camping use-case
#
[tantek] or a solar storm/flare knocks out satellites, cell towers etc. use-case, like tomorrow: https://www.natureworldnews.com/articles/52288/20220802/solar-storm-suns-atmospheric-hole-releases-geomagnetic-hit-earth-august.htm
#
aaronpk now that just sounds like secure scuttlebutt
#
aaronpk what is SSB?
#
Loqi Secure Scuttlebutt is a P2P system to sync message feeds, used to build (among others) social applications that work in off-grid/sneakernet scenarios https://indieweb.org/SSB