Focused crawls are collections of frequently-updated webcrawl data from narrow (as opposed to broad or wide) web crawls, often focused on a single domain or subdomain.
For the #IndieWeb ideals of independence from intermediaries, not requiring corporate platforms or other organizational intermediaries¹, the best systems we have still depend on organizations. However they are all swappable, at will, by the individual:
1. domain names, depend on registrars, which you can switch 2. web hosts, depend on hosting providers, which you can switch 3. internet access, depends on internet service providers, which you can switch 4. web browsing, depends on browsers, which you can switch 5. personal devices, that have choice of web browser and internet access, which you can switch, upgrade, and use multiples of simultaneously
When you can migrate from one provider to another, one device to another, without disruption, without breaking your people-to-people connections, the providers and devices serve you, instead of gatekeeping you.
This freedom to swap, freedom to choose, depends on practical #interoperability across multiple implementations, multiple services. Open standards are the means to encouraging, testing, and verifying this user-feature interoperability across implementations and services.
The #IndieWeb is for everyone, everyone who wants to be part of the world-wide-web of interconnected people. The social internet of people, a network of networks of people, connected peer-to-peer in human-scale groups, communities of locality and affinity.
These peer-to-peer links should not require corporate platforms or other organizational intermediaries, nor should they require depending on developer intermediaries, nor server administrator intermediaries.
This is the "indie" in IndieWeb, independence from intermediaries, not independence from people. Because the "web" in IndieWeb, is yes the Web of the World Wide Web, and it is also the Web of people.
The "indie" in IndieWeb is also the independent agency to opt-into human-scale groups, opt-into peer-to-peer connections, opt-into communities, opt-into publics. As the POSSE page says: “Figure out how you want to fit into the network”.
The "web" in IndieWeb is also an open acknowledgment and acceptance that regardless of what groups, connections, communities, and publics you opt-into, that they are all interconnected in a larger web, that even without connecting, you can accept and respect from a distance.
The IndieWeb is for everyone, everyone who wants independence from organizations, independence of agency to associate, and who embraces the web of humans that want to interconnect, to communicate, to value and respect each other, whether one degree apart or thirty.¹
@snarfed.org posted a great overview of thoughtful (and sometimes heated) discussions across blogs and the #fediverse about how freely should “public” posts & comments on the web flow across sites:
If you are designing or creating any kind of publishing or social features on the web, this post is for you.
It touches on topics ranging from #contextCollapse to #federation to #moderation and everything in between.
Does your choice of publishing tool set expectations about where your content might propagate, or whether it will be indexed by search engines? Should it?
Do the limitations of your server (e.g. js;dr) imply limitations of where your posts go, or whether they can be searched or archived? Should they?
When you post something publicly, are you truly posting it for a global audience for all time, or only for one or a few more limited #publics for an ephemerality?
When you reply to a post, do you expect your reply to only be visible in the context you posted it, or do you expect it to travel alongside that post to anywhere it might propagate to?
On the #IndieWeb, especially for public posts, some of these questions have easier and more obvious answers, because the intent of nearly all public IndieWeb posts is to interact across the web with other posts and sites, typically via the #Webmention protocol. However there are still questions.
Are the expectations for a blog and blogging different from a social media site, whether a silo or an instance on a network?
Is a personal website with posts still just a blog, or does it become something new when you start posting responses from your site, or receiving (e.g. via Webmention) and displaying responses from across the web to your posts on your site? Or is it now a “social website”?
If you have a social website, what is your responsibility for keeping it, well, social? Do you moderate Webmentions by default? Do you use the Vouch extension for some automatic moderation?
Are #POSSE & #backfeed different from federation or are they the same thing from a user-perspective, with merely different names hinting at different implementations?
Do you allow anyone from any site to respond or react to your posts? Or do you treat your social website like your home, and follow what I like to call a “house party protocol”, only letting in those you know, and perhaps allowing them to bring a +1 or 2?
I have many more questions. Each of these deserves thoughtful discussions, documentation of what different tools & services do today that we can try out, learn from, and use to make considered decisions when creating new things to post on and across websites.
31 days of #IndieWeb gifts: the _2023 IndieWeb Gift Calendar_ (https://indieweb.org/2023-12-indieweb-gift-calendar) wrapped up a full month of IndieWeb-related creations & updates from the community (and sometimes beyond) to everyone who wants to improve their #IndieWeb experience.
From plugins & libraries, to tools & services, to events & meetups, to web components & wiki pages, and blog posts & newsletters, there was something for everyone.
Some numbers: 🎁 71 total gifts 📄 32 new IndieWeb wiki pages 📜 8 posts on improving blogs, IndieWeb specs, and event summaries 💻 7 Online meetups: IndieWeb CreateFest & 6 Homebrew Website Clubs 🧩 6 plugin updates: #Elgg IndieWeb & 5 #WordPress plugins updates 📫 5 This Week In The IndieWeb newsletters 🧱 4 library updates: new web components, #microformats2 parser update 🌉 3 Bridgy Fed updates & improvements 🎪 2 days of #IndieWebCamp San Diego 📚 1 indiebookclub new year in review overview feature 📽 1 IndieWeb movie viewings aggregator ⌨️ 1 personal predictive text engine 🧶 1 #Threads federating out #ActivityPub (followable by #BridgyFed)
Gift were shared by: 👥 21 individuals 🏢 1 company
I compiled these numbers by hand. Let me know if you see any errors. There are many more potential stats like: * average (mean and median) number of gifts per contributor * how many edits to the Gift Calendar wiki page * how many different editors of the wiki page * average (mean and median) number of edits per editor I’ll leave those as exercises for others if they wish!
Time to begin again: restarting my #100Days of #IndieWeb project for 2024, as a #100Posts of IndieWeb project, and congrats to the IndieWeb community on a fully completed 2023 IndieWeb Gift Calendar!
Last year I completed 48 out of a planned 100 posts in my #100DaysOfIndieWeb project, for nearly 48 days (some days had multiple posts). Instead of resetting my goals accordingly, say down to 50, I’m going for 100 again, however, this time for 100 posts rather than 100 days, having learned that some days I find the time for multiple posts, and other days none at all.
Looking back to the start of last year’s 100 Days project, it’s been one year since I encouraged everyone to own their own notes¹. Since then many have started, restarted, or expanded their personal sites to do so. Some have switched from a #Twitter account to a #Mastodon (or other #fediverse) account as a stopgap for short-form status posts. A step in the right direction, yet also an opportunity to take the leap this year to fully own their identity and posts on the web.
In 2023 Twitter also broke all existing API clients (including my website). I did not feel it was worth my time to re-apply for an API key and rebuild/retest any necessary code for my semi-automatic #POSSE publishing, not knowing when they might break things again (since there was no rational reason for them to have broken things in the first place).
I manually POSSEd a few posts after that, yet from the lack of interactions, either Twitter’s feed algorithm² isn’t showing my posts, or people have largely left or stopped using Twitter.
Either way, when your friends stop seeing your posts on a silo, there’s no need to spend any time POSSEing to it.
On the positive side, the IndieWeb community really came together in 2023, shining brightly even through the darker days of December.
We, the IndieWeb community (and some beyond!) provided a gift (or often multiple) to the rest of community for every single day of December 2023³, the first time we successfully filled out the whole month since the 2018 IndieWeb Challenge⁴, and only the second time ever in the seven years of the IndieWeb Challenge-turned-Gift-Calendar.
By going through the various gifts (more than 2 per day on average!), there are many interesting numbers and patterns we could surface. That deserves its own post however, as does a summary of the 48 posts⁵ of my 2023 100 Days of IndieWeb attempt, so I’ll end this post here.
Happy New Year to all, with an especially well deserved congratulations to the IndieWeb community and everyone who contributed to the 2023 Gift Calendar. Well done!
Let’s see what else we can create & share on our personal sites in 2024 and continue setting a higher bar for the independent web by showing instead of telling. #ShowDontTell
“No large language models were used in the production of this document.”
I have added a similar disclaimer to the footer of my homepage:
“No large language models were used in the production of this site.”
2023 was certainly a year that LLMs took off and stole the hypecycle from #metaverse and #blockchain before that.
Yet unlike those previous two, #LLMs are already having real impacts on the way people create (from emails to art), communicate (LLM chat apps), and work (2023 Writer’s Strike), fueling growing concerns about the authenticity of content, especially content from human authors.
I expect we will see more such disclaimers in the future.
For now, if you blog on your own site with words written by you not #ChatGPT or a similar tool, I encourage you to add a similar disclaimer, and then add your site as an example to the #IndieWeb wiki: * https://indieweb.org/LLM#IndieWeb_Examples
#largeLanguageModel #LLM #generativeAI #AI
There is the related problem of, when you discover what seems to be an independent site written by a human, how do you know that human actually exists?
For now I’ll mention that XFN rel=met links, published (e.g. metrolls / met-rolls), aggregated, indexed, and queried, can solve that problem. This will be similar to how XFN rel=me links solved #distributed verification on the web (see https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me and posts it links to).
Writing about writing: capture first, edit & publish later.
Braindump timely thoughts & experiences into as many draft notes as it takes, while ideas & memories are fresh.
Collecting higher fidelity memories seems more important than editing past writings or finishing/polishing a post for publishing, which can be done at a later time.
Sometimes the passage of time helps provide insights and broader understandings that can help with writing more effective posts, from better summaries to narratives that help sense-making.
Bits of even this minor post sat for weeks, and only today did I add a summary and related thoughts.
Similarly, it makes sense to edit and publish small notes on a subject, without feeling compelled to turn them into a larger blog post, or a longer list of points.
This is a key advantage to publishing on your own #indieweb site, you decide on the granularity of your posts, small, medium or large, instead of being constrained, burdened, or pressured by any particular #socialMedia user interface, character count limitation, or audience expectation.
Like Twitter before it, even the default #Mastodon user interface has limitations, and the #fediverse itself as a whole has audience/cultural expectations (certainly quite a few articles have been written about that).
On your own site you decide if you want to publish a post to make one point, or mention a related point or two, or collect things into a list or longer article, or eventually all of the above.
On your own site you feel more free to prioritize and share what is on your mind, instead of feeling compelled to first respond to whatever topics are trending, or to whatever you happen to read in your algorithmic feed.
at the first ever #IndieWebCamp San Diego, documented a bunch of discussions and content in new and updated wiki pages on https://indieweb.org/ and updated my home page static events listing.
at a fascinating #Threads meetup hosted by Meta in San Francisco, with a handful of great #dataportability #fediverse #indieweb #openweb folks, learning about and providing feedback to Threads folks about their #federation #ActivityPub and other #openStandards support plans.
Chatham House rule¹ means we can quote and talk about what’s being discussed (I’m taking notes), however no attribution, which I’m extending to not saying (or @-@-mentioning) who else is here.
If you’re also here, feel free to reply to this post or use one of the below hashtags. And since I’m publishing this, feel free to @-me as well.
#DataDialogue #Threadiverse (unofficial hashtag suggestion from a participant)
coding at #IndieWebCamp Nuremberg, completed the following projects:
0.0: fixed the https://chat.indieweb.org/ footer to drop #Matrix as an access option since their bridge is disabled (#IndieWeb IRC, Discord, and Slack still work great), and provided an explicit link/encouragement for filing issues
0.7: added HTML <search> element support to my home page and permalinks as nerdsniped by @adactio.com (@adactio@mastodon.social@adactio); expanded to <search role=search> to also support folks using older browsers / screenreaders that only support #ARIA 1.1.
0.8: replaced my incorrect use of HTML attribute aria-hidden="true" (on my links to #BridgyFed) as pointed out by @jkphl.is (@jkphl@mastodon.social@jkphl) and https://sonja-weckenmann.de (@sweckenmann@mas.to), with hidden="from-humans". Since other values are allowed on the hidden attribute and treated as hidden="hidden", the "from-humans" value communicates a subtle semantic that the element is intended for consumption by robots & crawlers, like #Bridgy. 0.8.1 Update: created a pull-request (https://github.com/snarfed/bridgy-fed/pull/701) to update the BridgyFed documentation markup examples to use the 'hidden' attribute accordingly as well. Update 2: it's been merged! e.g. https://fed.brid.gy/docs#how-post
Time is up for today’s IndieWebCamp Create Day so my remaining projects will have to wait.
Looking forward to the next two days at #IndieWebCamp Nürnberg @tollwerk.de (@tollwerk@mastodon.social@tollwerk) of personal site demos, brainstorming sessions, and making, creating, & hacking things from UX to protocols to improve & interconnect our websites, with each other ( #Webmention ), #fediverse ( #BridgyFed & #ActivityPub ), and others ( #POSSE #backfeed ).
Still a few spots if you’re in town or can hop on a train and join us Saturday & Sunday!
“In a POSSE world, everybody owns a domain name, and everybody has a blog. (… a place on the internet where you post your stuff and others consume it.)”
Second, syndicate elsewhere, appropriately for each destination:
“Then, your long blog post might be broken into chunks and posted as a thread on X and Mastodon and Threads. The whole thing might go to your Medium page and your Tumblr and your LinkedIn profile, too. If you post a photo, it might go straight to Instagram, and a vertical video would whoosh straight to TikTok, Reels, and Shorts. Your post appears natively on all of those platforms,”
You can use Bridgy Publish (https://brid.gy/) to POSSE to many destinations, and Bridgy Fed (https://fed.brid.gy/) to #federate to #Mastodon and other #fediverse destinations, directly from your site instead of posting a copy on yet another account on yet another server.
Third, and this is a key piece that distinguishes proper POSSE setups, with original post perma(short)links back to your posts on your domain:
“typically with some kind of link back to your blog.”
All copies link to (your) home.
"And your blog becomes the hub for everything, your main home on the internet."
You have power over your domain (name), not outside silos.
David embedded a screenshot of one of my posts, a reply post:
in which I posted a reply *on my own site*¹ to @Zeldman.com’s tweet (itself a reply to a POSSE copy of one of my posts), and POSSEd my reply to Twitter so it would thread with his reply.
This illustrates another important detail of a proper POSSE setup:
Fourth, post *replies* and other responses from your own site, whether to other IndieWeb sites, or to others’s silo posts (tweets etc.).
Own your data means owning your replies as well.
David also noted several challenges and good questions about POSSE. Some of these have answers & established practices, others are areas of exploration. E.g.
"The first is the social side of social media: what do you do with all the likes, replies, comments, and everything else that comes with your posts?"
Backfeed is a concept I first wrote about as “reverse syndication”².
As you syndicate your posts out to #socialMedia silos, you reverse syndicate any responses there back to your original post.
Your site can do this with a service like #Bridgy, which uses the #Webmention standard to forward such silo responses back to your site, and #BridgyFed which does same for responses from Mastodon to your #federated posts.
David asked many other questions, which are deserving of their own posts to help answer, so I’ll leave you with just one more:
"The most immediate question, though, is simply how to build a POSSE system that works."
Even if you have to do it manually (until it hurts), even if you have to edit your posts on a static GitHub site (behind your domain name of course), and then copy & paste to your silo(s) of choice, just start.
By practicing POSSE, even manually, you will learn what aspects of POSSE & backfeed matter the most to you, what aspects actually involve reaching & responding to friends and others you care about.
By doing so you will naturally focus on setting up & making what you need, and you too can join the future of web publishing, today.
Implemented liking/favoriting of #Mastodon posts via Bridgy Fed on my site! (Actually of any post on any site that #BridgyFed can discover an #ActivityPub endpoint to send likes to.)
Tested it by liking @evanp.me (@evan@cosocial.ca@evanpro)’s reply¹ confirming that he received a notification from my prior post². I sent a #Webmention from my like post³ to Bridgy Fed, and it #federated the like to Evan’s server, which subsequently showed up in the "favourites" list of Evan’s post:
Ben Werdmuller
recently published an inspiring and thought-provoking blog post:
“Subscribing to the blogs of people I follow on Mastodon”.
Beyond the insights and excellent developer how-to in his post, I believe it points to something larger: a fundamental thoughtfulness difference between writing rapid short-form posts (whether tweets or toots) and medium or longer form writing (on blogs or journals), and the impact of that difference on readers: that the act of reading more thoughtful writing nudges & reinforces a reader into a more thoughtful state of mind.
If you have not read
Derek Powazek’s watershed blog post
“The Argument Machine”,
I highly recommend you do so. In the nearly ten years since his post, Derek’s hypothesis of Twitter’s user interface design being the ultimate machine to create & amplify disputes has been repeatedly demonstrated.
Derek’s post predated Mastodon’s release by nearly three years. Ironically, by replicating much of Twitter’s user experience, Mastodon has in many ways also replicated its Argument Machine effects, except distributed across more servers.
I’ve witnessed numerous otherwise rational, well-intentioned individuals write reactive posts on Mastodon, exactly what the Twitter-like interface encourages. Quick emotional responses rather than slower, more thoughtful posts and replies.
I’ve seen the artificial urgency of tweets & toots bleed over into emotional essays on public mailing lists. New participants join a list and immediately make entitled demands. Fearful bordering on paranoid assumptions are used to state assertions of “facts” without citations. Arguments are made that
appeal to emotion
(argumentum ad passiones)
rather than reasoning from principles and shared values.
Implicit in Ben’s post, “Subscribing to the blogs of people”
(emphasis mine), is a preference for reading longer form writing, published on a site a human owns & identifies with (a la
#indieweb),
neither silo nor
someone
else’s garage.
The combination of taking more time (as longer form writing encourages) and publishing on a domain associated with your name, your identity, enables & incentivizes more thoughtful writing. More thoughtful writing elevates the reader to a more thoughtful state of mind.
There is also a self-care aspect to this kind of deliberate shift. Ben wrote that he found himself “craving more nuance and depth” among “quick, in-the-now status updates”. I believe this points to a scarcity of thoughtfulness in such short form writings. Spending more time reading thoughtful posts not only alleviates such scarcity, it can also displace the artificial sense of urgency to respond when scrolling through soundbyte status updates.
When I returned from
#W3CTPAC,
I made a list of all the thoughts, meetings, sessions that I wanted to write-up and publish as blog posts to capture my experiences, perspectives, and insights beyond any official minutes.
Yet due to distractions such as catching up on short form posts, it took me over a week to write-up even a
summary of my
TPAC week, nevermind the queue of per-topic notes I wanted to write-up. To even publish that I had to stop and cut-off reading short form posts, as well as ignoring (mostly postponing) numerous notifications.
There’s a larger connection here between
thoughtfulreading,
and finding, restoring, and rebuilding the ability to focus, a key to thoughtful
writing.
It requires not only reducing time spent on short form reading (and writing), but also reducing
notifications,
especially push notifications. That insight led me to wade into and garden the respective IndieWeb wiki pages for
notifications,
push notifications,
and document a new page for
notification fatigue.
That broader topic of what do to about notifications is worth its own blog post (or a few), and a good place to end this post.
Thanks again Ben for your blog post. May we spend more time reading & writing such thoughtful posts.
because I forgot to put explicit categories (p-category markup) in the article post.
Adding that markup after publishing, and then sending an ActivityPub update (via #BridgyFed) is apparently not enough for #Mastodon to notice that the Update has new tags to display and aggregate on tag pages. In my next #w3cTPAC article post I’ll be sure to include category markup before publishing and see if that works.
This year’s W3C TPAC (Technical Plenary and Advisory Committee) meetings felt denser in many ways, packed tighter with more topics, and more active participants. There were so many specific things in specific meetings, new connections, victories, new challenges, that in addition to capturing summary notes, I'm considering writing blog posts about each meeting or session.
Nearly all of them have public minutes that document both participants, and a good portion of what was discussed. I have my own notes, and combined with recollected details of what was minuted, I have my own observations to share. I encourage everyone who participated at TPAC (whether in-person or remote) to consider either writing a summary blog post about the experience, perhaps highlighting a few things that stood out, or if there were specific technical discussions that advanced something in a positive direction, or challenges blocking progress, those are worth their own blog posts as well.
TPAC week 2023
took place from Monday
through Friday
,
in
Sevilla,
Spain.
Here is a summary outline of meetings, sessions, and discussions I participated in. Not listed: conversations at breakfasts, morning & afternoon breaks, lunches, dinners, and of course hallways. Unlinked for now, each of these has a calendar event with description, minutes, almost all of which are public.
Monday
WICG (Web Incubator Community Group)
Tuesday
Social Web Incubator CG (community group), AKA
SocialCG or
SWICG
DID WG
rechartering discussion
AC meeting
Vision TF
Fediverse meetup
Wednesday — Breakouts day!
Chartering at W3C
Technical Roadmap at W3C
SocialWeb Test Suite Discussion
SocialWeb Data Portability Discussion
Introducing the Web
Sustainability
Guidelines (WSGs)
Report to Members, Hearing from Members
Technical Plenary reception
Thursday
CSS WG, briefly
Afternoon break:
Solid
charter discussions, use-cases,
IndieWeb Micropub,
ActivityPub
Friday
Social CG planning
Departing conversations & reflections
Those are the sessions & discussions that I found in my notes.
I also met a lot of new people during meetings, meals, and discussions at breaks.
As I write up my notes on specific sessions and their minutes (and hyperlink the above list items), I expect to recall more context and details. If you were at TPAC in
Seville,
I encourage you to write-up your experiences as well, while the thoughts, feelings, and insights are fresh in your mind. By documenting & publishing our collective experiences (using the
#w3cTPAC
hashtag) we can build upon them together.
:format(webp)/cdn.vox-cdn.com/uploads/chorus_asset/file/25024444/CleanShot_2023_10_23_at_09.36.40_2x.png)