#dev 2024-11-05

2024-11-05 UTC
zeke, GuestZero, claudinec, troojg, geoffo, Ellie, claudine, nandv, thegreekgeek, ACG, dustinm`, Tiffany, rrix, oxtyped-, srijan, box464, nsh, jan6, athenaeryma, dissolve22[d], aaronpk, joshproehl, oenone, Soni, chenghiz_, moose333, DJ_[dj_je][d], thegr8whoopdini[, capjamesg[d], ludovicchabant, rhiaro, schmudde1, Virtual, vroman, ms_boba[d], omz13, kushal, Salt, sknebel, rjomara5853, ben, mooff, sandra, voxpelli, Elleo, lockywolf, superkuh, sebsel, [0x3b0b], fluffy, alephalpha0, IWDiscord, Pixi, sisoma_new[d], onla_, strugee_, revi, Dryusdan, AcesAndEights, shimpbizkit[d], benji, GWG, vikanezrimaya, suki, srushe, ancarda, roxwize, capjamesg, saptaks_znc, eb, nnrx, Maxpm, [tantek], onla, parnikkapore_x, streety, Zegnat, Xe, karjala, grufwub, jonnybarnes, oodani, JadedBlueEyes, rolle, [Joe_Crawford], magni, [morganm], IWSlackGateway, jeremycherfas, [mattl], lanodan, [qubyte], [Ana_R], [Murray], AramZS, sebbu, bret, [aciccarello], gRegor, [snarfed], sivoais, [benatwork], Saphire, natoshi-sakamoto, glacier, thegreekgeek_ and frxi joined the channel
#
glacier
Was reading more about h-entry and discovered that since I've been using h-entry on my updates page that all new updates can be read in an RSS reader that supports images and HTML, which is pretty awesome. but now it seems slightly redundant with the manual RSS feed I've been making which doesn't have images and has much shorter descriptions. Do the old style RSS feeds work better in some contexts, like bare bones readers that only grab text?
#
glacier
another question, do h-entry link previews work differently than open graph protocols?
nandv, abyss and grufwub joined the channel
#
glacier
sorry I'm going to move my question to #microformats, I forgot there was such a channel (I'm on IRC)
abyss, [KevinMarks], AramZS and [tw2113] joined the channel
#
[snarfed]
0x3b0b thanks again for the microblogpub + granary nudge! I chimed in on https://github.com/orgs/microblog-pub/discussions/16#discussioncomment-11158622
[snarfed]1, IWSlackGateway5, [Murray]1, [mattl]1, [KevinMarks]1, [morganm]1, [Joe_Crawford]1, [benatwork]1 and jimw joined the channel
#
[snarfed]
[aaronpk] heads up on [j12t]'s feditest (webfinger) conformance test results for p3k: https://feditest.org/contrib/results/2024-06-16/index.p3k.html
gRegorLove_ joined the channel
#
[tantek]
[snarfed] are the tests actually testing things that matter to use-cases and interop or are they abstract webfinger tests?
#
[tantek]
Separately we really need to write up a "instead of Webfinger, publish and implement these FYND methods instead" doc
#
[snarfed]
they're standards compliance tests
#
[tantek]
Which satisfies the actual use-cases rather than than "all of webfinger" which no one should ever have to waste time with
#
[snarfed]
the intent is to eventually do the same for AP
#
[snarfed]
sure, that's a good way to prioritize
#
[snarfed]
but you also advocate for standards compliance test suites in general, right?
#
[tantek]
Alternatively, user implementation experience to reduce webfinger to what's needed and drop all the features that implementations ignore or fail
#
[snarfed]
I mean, I get the priority point. just odd to hear you doubting compliance test suites
#
[snarfed]
if the real criticism is aimed at webfinger itself, sure
#
[tantek]
Because webfinger never properly went thru a "CR" phase where each feature is evaluated by if it matters to implementations or not
#
[snarfed]
sure. so, separate from whether compliance test suites are good
#
[tantek]
I am strongly against large abstract specs that with large grab bags of abstract features that were never implementation tested
#
[tantek]
So no, "compliance" tests of large abstract specs are counter-productive and a waste of time IMO
#
[tantek]
INTEROP tests of what's actually implemented are good
#
[tantek]
And then such specs should be subsetted to what's actually needed by implementations for real world use-cases
#
[snarfed]
webfinger never struck me as a particularly large spec with a ton of abstract features, but I doubt I've actually read it end to end
#
[snarfed]
I wasn't really looking to argue any of these bigger points, just wanted to nudge aaronpk
#
[tantek]
Implementations should absolutely reject and vote (with their code) against "compliance" tests that are disconnected from actual user-relevant features
#
[snarfed]
to be fair, that would require implementors to dig in and understand the whole breadth and depth of use cases, which may often be a big task, and is kind of hopefully what standards bodies are supposed to do - and are hopefully better at - so that implementors don't have to, right?
#
[snarfed]
(ideal world vs real world, granted)
#
[snarfed]
I guess I'd worry a bit about different implementors only knowing/caring about their own subset of use cases, so if they feel encouraged to ignore compliance for anything else, that hurts interop for features that are still user-relevant, right?
#
[snarfed]
(goddammit here I am arguing after all 😁)
superkuh joined the channel