[snarfed]you're right that web site owners have definitely the main BF target audience _so far_, and federating those sites into the fediverse has been the main use case. I'm deliberately trying to expand that use case and target audience, though, to anyone on any supported network, with no setup
[snarfed]specifically, I'm making web sites zero setup by reading profiles from metaformats, polling feeds to get posts in addition to the current webmention trigger, and not requiring webfinger redirects
[snarfed]I don't mean the redesign to imply that following is is the only main use case, but since federating web site is automatic now, no setup required, and posts soon too, I see following as one of the most immediately user-visible and impactful ways to get started
[snarfed]and I do know you liked the table. I did too! out of about a dozen other people I got feedback from though, no one else understood or liked it, even when I explained and got them past the lack of styling
[snarfed]I plan to revisit it when I add the next network, at least if I can figure out how to do it on phones. for now though, even for just two networks, based on those dozen people and my own judgment, it seemed more net harmful than helpful
[tantek]yep, if the table didn't resonate with others, can it. what I liked more was the network diagrams in the prior homepage, and with those missing I feel something significant has been lost in quickly conveying what BridgyFed does
[tantek][snarfed] does that mean BridgyFed will poll a site home page for its h-feed and then auto-federate new posts?!? (sounds like per the docs that's not the case yet https://fed.brid.gy/docs#web-how-post but I'm wondering if that's your goal)
gRegorI guess my homepage would be OK, I don't have replies on there now. But there are also post types on there I know BF doesn't support, like bookmarks.
[snarfed]right, BF will soon poll feeds and auto-federate posts. right now I'm thinking it will only do that until you send your first wm to it, and then it will switch to wm-only trigger, but that might be surprising, so I"m not sure yet
[snarfed]and yeah replies/likes/reposts etc are already pretty advanced, so I think I'm ok with expecting wms for those, at least if they're not in the main h-feed
[snarfed]you're also probably right that for web users, even with zero setup, they'll probably first think "how do I get my web site visible in the fediverse" before "how can I follow someone from my web site." I can revise the front page language for that
gRegorWould we be grandfathered in since we've already sent wm then? A setting we can toggle might be nice. I'm leaning towards continuing to send wm for each post, but maybe in the future I'd try switching to auto-federate
[tantek]maybe even something that their dashboard would eventually prompt after a few successful posts via webmention, that BridgyFed has confirmed it found on their h-feed
[tantek]"Hey Alice, congrats on federating 5 posts to from your website directly to the fediverse! BridgyFed also found those 5 posts on your main home page feed. In the future if you'd like, BridgyFed could auto-federate new posts it finds on your home page. Would you like to enable auto-federation of new posts?"
sknebelhm, automatic (=not-opt-in) bridging of networks is a bit questionable. I know a bunch of people got upset by the various "follow twitter users through activitypub" gateways (and some instances do block anything like that)
[snarfed]I still use the diagrams in Bridgy classic when you click the Mastodon button: https://brid.gy/which-bridgy , and I definitely agree that they're valuable for web users specifically. they felt too big and heavy and single-protocol to keep on the front page, but I should put them back into the docs at least
[snarfed]opt in for bridging at all...a number of us have discussed it, and I get the idea, but it would radically reduce the number of users available, which would make the bridge waaaay less useful
[snarfed]ie _inside_ each network, if your profile is public, people on other instances (on the web and in the fediverse, Bluesky, Nostr) default to seeing your posts. you have to take an action to do anything else
gRegorHm, yeah I'm still very much in Bridgy Classic Publish mindset. It's not too often, but not rare that I post a note I don't intend to POSSE or federate
sknebel"I just joined here, and if people search my common user name they find 6 accounts, 5 of which are bridges, 4 of which broke down at various points and stopped updating and/or kept posts I deleted on the other side online" was the usual experience with the twitter bridges
sknebelbut deletions and edits are an example: without my site actively using e.g. webmentions to keep you up to date, you won't be able to reliably federate those
[snarfed](opt in bridging probably wouldn't solve duplicates anyway, since the most common way fedi people opt into/out of things is per "class" of tool, ie "searchable" or "nobot" or "nobridge" in profile, more often then per individual tool)
sknebelI dont think "add an extra feature to your site to be able to delete your content from a thing you might not even know exists" is well-framed as "a good motivation"
[snarfed]sknebel fair. if they don't want to be bridged at all, opt out does that. if they do, and they want to make sure a delete is federated, wms might be more reasonable, and maybe also a form in the BF web UI
[snarfed]if they aren't aware of BF, and we want to make sure a delete is federated...that's a harder one, agreed! I can definitely think about it, and I'm open to ideas
[snarfed](I'm more and more trying to think about BF questions like this from non-web angles, eg how would it work btw the fediverse and Bluesky, or the fediverse and Nostr, to inform how it could work for web users)
[tantek]Capjamesg++ nice!!! Also just noticed your wiki contributions sparkline! What are you using to generate that? And you could link that to your User Contributions page
[tantek]ooh I take it from the code on that page you don't mind if we use it to embed sparklines on our home pages? I may use the <img> tag instead of <embed> tho. any reason you used <embed> in the sample code capjamesg?
[tantek]you could auto-generate the link to the detailed list too, since all it takes is the username and wiki URL, e.g. <a href="https://indieweb.org/Special:Contributions/Jamesg.blog"><img ...
[tantek]does your server cache the API data or the images (e.g. only regenerate once a day) or is it live calling the MediaWiki API for each view of the embed?
[tantek]also this makes me wonder if that would be better as a building block caching service that you could run on your own server, for any kind of 3rd party embeds on your site
[tantek]would also have better privacy properties (having a cache service on your own site serve the embeds to your viewers, rather than a 3rd party site)
[tantek]it would do the caching on your personal server rather than the SVG generating server. your personal server would call, server to server, to regenerate the SVG when necessary
[tantek]E.g. on the front end (in the HTML served to browsers), I'd keep the markup as is (with <img> though) and then have something like (pseudo-code to break auto-linking) src="src.tantek .com/indiewebcontributions.svg/cache/1day/get/sparkline.jamesg.blog/?username=User:http://Tantek.com&api_url=http://indieweb.org/wiki/api.php&only_image=true". Then src.tantek would look for a cached file called indiewebcontributions.svg that was no more than 1
[tantek]dropping the /cache/1day/ URL segment params would cause it to always do the GET (from the /get) and regenerate, which you could do manually to flush the cache of that file
[tantek]capjamesg, this kind of setup would be kinder on your sparkline.jamesg server, and thus kinder on the MediaWiki API endpoint your server was calling, so your server didn't end up massively banging on someone else's server (e.g. say, Wikipedia) and thus get blocked/banned
[tantek]via such a caching service, so that Wikipedia does not end up blocking sparkline.jamesg for using its API "too much" (e.g. for every home page view I get)
[tantek]this feels like the kind of thing aaronpk would have built already, and if not, I may try a go at it, in PHP of course (which I know how to do all those things, check for a file existing, get info about the file, retrieve an external URL, write the results to a file, serve a file back as a user request)
[tantek]I'm not even sure how I'd search for a pre-existing library that did this in a very simple (read: one like one .php source file to handle the request, not a bunch of Composer this Object-Oriented that drivel) way. the only external dependency should be curl which should be installed & enabled in typical default PHP setups
[tantek]that reminds me, is there an OSS community that creates, and builds upon single code file libraries? or is that a lost art to all the package bloat npm install dependency hell cargo-culting?
[tantek]a little Googling and I found this example of a single PHP file library (haven't tried it, just interesting presentation on the web page about it) https://sye.dk/sfpg/
LoqiThe object-oriented-programming antipattern is the excessive / unnecessary use of object-oriented-programming (OOP) and OOP techniques when simple procedural functions would have sufficed, with less overhead, fewer files to navigate around, fewer indirections to follow while debugging, etc https://indieweb.org/OOP
[tantek]OOP encourages lots of time to be spent (wasted) with setting up a ton of boilerplate files (naming is hard), classes (naming is hard), methods (naming is hard), hierarchy (information architecture is hard), when a flat set of functions would suffice for 90%+ of use-cases, and the best way to discover that other 10% is to start flat and then only add hierarchy when the flat set of things gets too large and you need some "chunking" to make it
[tantek]OOP << Criticism: wastes too much time compared to actual utility (for both library creators/maintainers, and clients). OOP encourages lots of time to be spent (wasted) with setting up a ton of boilerplate files (naming is hard), classes (naming is hard), methods (naming is hard), hierarchy (information architecture is hard), when a flat set of functions would suffice for 90%+ of use-cases, and the best way to discover that other 10% is to
Loqiok, I added "Criticism: wastes too much time compared to actual utility (for both library creators/maintainers, and clients). OOP encourages lots of time to be spent (wasted) with setting up a ton of boilerplate files (naming is hard), classes (naming is hard), methods (naming is hard), hierarchy (information architecture is hard), when a flat set of functions would suffice for 90%+ of use-cases, and the best way to discover that other 10% is to" to the "See Also" section of /object-oriented-programming-antipatternhttps://indieweb.org/wiki/index.php?diff=91774&oldid=88663
[tantek]there's a lot of "but it will save you time in the long run" faith-based BS in OOP (and MVC) advocacy circles that has no evidence, and plenty of anecdotes that dispute it.
Zegnatshadcn/ui is the only modern project that gets close to the flat file thing. In that they literally tell developers to “Copy and paste the code into your project and customize to your needs” rather than depend on bringing in code through some package mmanager (npm)
ZegnatThough, as it is all React based, you are likely to already have a package manager anyway. Not a whole lot of projects running raw React as JS files these days.