Show Navigation
Notices tagged with bridgyfed
-
No I did not block you on the #fediverse / #Mastodon / #Misskey etc.
If you were following me @tantek.com on your client/server/instance of choice but noticed you were no longer doing so, that was due to a recent software bug in my fediverse provider which accidentally caused everyone’s #ActivityPub servers to unfollow me (bug details below).
No it’s absolutely not your fault, you did nothing wrong.
We need a variant of Hanlon’s Razor¹ like:
“Never attribute to malice that which is adequately explained by a software bug.”
Take another look at my posts if you want (directly on @tantek.com or try searching for that on your instance) and if you like what you see or find them otherwise informative and useful, feel free to refollow. If not, no worries!
Also no worries if you ever unfollow/refollow for any reason. I mean that.
I always assume people know best how to manage their online reader/reading experiences, everyone’s priorities and likes/dislikes change over time, and encourage everyone to make choices that are best for their mental health and overall joy online.
Bug details:
This was due to a #BridgyFed bug² that deleted my profile (“ActivityPub actor”) from (nearly?) all instances, making everyone’s accounts automatically unfollow me, as well as remove any of my posts from your likes and reposts (boosts) collections. It also removed my posts from any of your replies to my posts, leaving your replies dangling without reply-contexts. Apologies!
The bug was introduced accidentally as part of another fix about a month ago³, and was triggered within the following week⁴.
Anyone following me before ~2024-09-22 was no longer following me. A few folks have noticed and refollowed. Any likes or reposts of my posts before that date were also undone (removed).
Ryan (@snarfed.org) has been really good about giving folks a heads-up, and apologizing, and quickly doing what he can to fix things.
Bugs happen, yes even in production code, so please do not post/send any hate.
I’d rather be one of the folks helping with improving BridgyFed, and temporary setbacks like this are part of being an early / eager #IndieWeb adopter.
This bug has also revealed some potential weaknesses in other ActivityPub implementations. E.g. deleting an “actor” should be undoable, and undoing a delete should reconnect everything, from follows to likes & reposts collections, to reply-contexts. Perhaps the ActivityPub specification could be updated with such guidance (if it hasn’t been already, I need to double-check).
To be clear, I’m still a big supporter of #BridgyFed, #ActivityPub, #Webmention, and everyone who chooses to implement these and other #IndieWeb related and adjacent protocols as best fits their products and services.
All of these are a part of our broader open #socialWeb, and making all these #openStandards work well together (including handling edge-cases and mistakes!) is essential for providing #socialMedia alternatives that put users first.
References:
¹ https://en.wikipedia.org/wiki/Hanlon%27s_razor
² https://github.com/snarfed/bridgy-fed/issues/1379
³ https://github.com/snarfed/bridgy-fed/commit/4df76d0db7b87cabbd714039546c05b3221169be
⁴ https://chat.indieweb.org/dev/2024-09-22#t1727028174623700
This is post 26 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/285/t1/io-domain-suggested-steps
→ 🔮
-
Tip: use the W3C Link Checker and fix any errors before federating with Bridgy Fed.
https://validator.w3.org/checklink
If you are using Bridgy Fed to federate your posts from your personal site, I highly recommend you first run the W3C Link Checker on a post, and verify there are no “red” errors (or fix any you find), before pinging Bridgy Fed to federate the post.
The reason is that if your post contains broken links, especially broken https: links as part of an @-mention, a weird set of timeout interactions will occur between #BridgyFed and #Mastodon that will cause any Mastodon instances following your posts to drop your federated posts as if they had not been received.
Further, those instances will also ignore any UPDATES to that post.
More discussion here:
* https://chat.indieweb.org/dev/2024-09-04#t1725421768496000
More bug details here:
* https://github.com/snarfed/bridgy-fed/issues/884#issuecomment-2327861883
#IndieWeb #federate #fediverse #interoperability
This is post 22 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/246/t1/adventures-indieweb-activitypub-bridgy-fed
→ 🔮
-
A couple of days ago in an informal discussion in the #indieweb chat channel about how different people view #Mastodon, the #fediverse, or #Bluesky, and services like #Bridgy & #BridgyFed quite differently, I noted¹ that one big unspoken difference was how things on the web last over time, from the traditional persistent web, vs the newer and growing ephemeral web.
There is the publicly viewable #OpenWeb that many of us take for granted, meaning the web that is persistent, that lasts over time, and thanks to being #curlable, that the Internet Archive archives, and that a plurality of search engines see and index (robots.txt allowing). The HTML + CSS + media files declarative web.
Then there are the https APIs that return JSON "web", the thing that I’ve started calling the ephemeral web, the set of things that are here today, briefly, gone tomorrow. I’ve previously used the more provocative phrase js;dr (JavaScript required, Didn’t Read) for this #ephemeralWeb, yet like many things, it turns out there is a spectrum from ephemeral to persistent.
One popular example on that spectrum that’s closer to the ephemeral edge is anything on a Mastodon server running v4 (or later as of this writing) of the software. (I’m not bothering to discuss the examples of walled garden social media silos because I expect we will continue to see their demise² over time.)
For example, the Internet Archive version of the shutdown notice for the queer(.)af Mastodon server, is visibly blank:
https://web.archive.org/web/20240112165635/https://queer.af/@postmaster/111733741786950083
Note: only a single Internet Archive snapshot was made of that post.
However if you View Source, you can find the entirety of that #queerAF post duplicated across a couple of invisible-to-the-user meta tags inside the raw HTML:
"**TL;DR: Queer[.]AF will close on 2024-04-12** …"
[.] added to avoid linking to a dead domain.
Note: such meta tags in js;dr pages were part of the motivation to specify metaformats.
To be clear, the shutdown of queer(.)af was a tragedy and not the fault of the creators, administrators etc., but rather one of the unfortunate outcomes of using some ccTLDs, country-code top level domains, that risk sudden draconian rules, domain renewal price hikes, or other unpredictable risks due to the politics, turmoil, regime changes etc. of the countries that administrate such domains.
Nearly the entirety of every Mastodon server, every post, every reply, is ephemeral.
When a Mastodon server shuts down, all its posts disappear from the surface of the web, forever.
Perhaps internet archeologists of the future will discover such dead permalinks, check the Internet Archive, find apparent desolation, and a few of them will be curious enough to use View Source tools to unearth parts of those posts, unintentionally preserved inside ceremonial meta tags next to dead scripts disconnected from databases and an empty shell of a body.
All reply-contexts of and replies to such posts and conversations lost, like threads unraveled from an ancient tapestry, scattered to the winds.
If you’re reading this post in your Mastodon reader, on either the website of your Mastodon account, or in a proprietary native client application, you should be able to click through, perhaps on the date-time stamp displayed to you, to view the original post on my website, where it is served in relatively simple declarative HTML + CSS with a bit of progressive enhancement script.
Because I serve declarative content, my posts are both findable across a variety of services & search engines, and archived by the Internet Archive. Even if my site goes down, snapshots or archives will be viewable elsewhere, with nearly the same fidelity of viewing them directly on my site.
This design for longevity is both deliberate, and the default for which the web was designed. It’s also one of the explicit principles in the IndieWeb community.
If that resonates with you, if creating, writing, & building things that last matter to you, choose web tools, services, and software that support the persistence & longevity of your work.
#persistentWeb #longWeb #LongNow
This is post 10 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/035/t2/indiewebcamp-brighton-tickets-available
→ 🔮
Post glossary:
API (Application Programming Interface)
https://indieweb.org/API
Bluesky
https://indieweb.org/Bluesky
Bridgy
https://brid.gy/
Bridgy Fed
https://fed.brid.gy/
ccTLD (country-code top level domain)
https://indieweb.org/ccTLD
curlable
https://indieweb.org/curlable
declarative web
https://www.mozilla.org/en-US/about/webvision/full/#thedeclarativeweb
Internet Archive
https://archive.org/
js;dr (JavaScript required; Didn’t Read)
https://tantek.com/2015/069/t1/js-dr-javascript-required-dead
JSON
https://indieweb.org/JSON
longevity
https://indieweb.org/longevity
Mastodon
https://indieweb.org/Mastodon
metaformats
https://microformats.org/wiki/metaformats
permalink
https://indieweb.org/permalink
principles in the IndieWeb community
https://indieweb.org/principles
progressive enhancement
https://indieweb.org/progressive_enhancement
reply
https://indieweb.org/reply
reply-context
https://indieweb.org/reply-context
robots.txt
https://indieweb.org/robots_txt
social media
https://indieweb.org/social_media
silo
https://indieweb.org/silo
View Source
https://firefox-source-docs.mozilla.org/devtools-user/view_source/index.html
¹ https://chat.indieweb.org/2024-02-13#t1707845454695700
² https://indieweb.org/site-deaths
-
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:
🎁 67 total gifts
📄 32 new IndieWeb wiki pages
📜 7 posts on improving blogs, IndieWeb specs, and event summaries
💻 6 Homebrew Website Club online meetups
📫 5 This Week In The IndieWeb newsletters
🧱 4 library updates: new web components, #microformats2 parser update
🌉 3 Bridgy Fed updates & improvements
🧩 2 plugin updates: #Elgg IndieWeb & #WordPress #IndieAuth
🎪 1 #IndieWebCamp San Diego (2 days!)
📚 1 indiebookclub new year in review overview feature
📽 1 IndieWeb movie viewings aggregator
🧶 1 #Threads federating out #ActivityPub (followable by #BridgyFed)
Gift were shared by:
👥 20 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!
This is post 2 of #100PostsOfIndieWeb. #100Posts
← https://tantek.com/2024/001/t1/restarting-100days-indieweb-gift-calendar
→ 🔮
-
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 provide an explicit link/encouragement for filing issues
0.5: investigated IndieWeb wiki issues (mobile presentation), possible fixes, and documented them: https://indieweb.org/MediaWiki_customizations#Issues
0.7: add 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.
Time is up for today’s IndieWebCamp Create Day so my remaining projects will have to wait.
-
Inspiring mix of perspective expanding and personal talks at border:none (https://border-none.net/ @border_none) the past two days. Thanks speakers, volunteers, and especially organizers @marcthiele.com (@marcthiele@mastodon.social @marcthiele) and @jkphl.is (@jkphl@mastodon.social @jkphl).
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!
🎟 Tickets: https://ti.to/beyondtellerrand/bordernone-2023/with/kqyaidtq92k
🗓 Event: https://events.indieweb.org/2023/10/indiewebcamp-nuremberg-2023-DmXe4dYdfagc
ℹ️ More info: https://indieweb.org/2023/Nuremberg
#bordernone #bono23 #IndieWeb
-
Great article on #POSSE by David Pierce (@davidpierce@mastodon.social @pierce) @Verge:
https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon
Several key points of POSSE explained in the article:
First, post on your own site:
“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?"
The short answer is #backfeed: https://indieweb.org/backfeed
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."
The short answer is: just start³.
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.
Questions? Join us in the chat: https://chat.indieweb.org/ (also on Discord, IRC, and Slack⁴)
This is day 46 of #100DaysOfIndieWeb. #100Days
← Day 45: https://tantek.com/2023/289/t1/bridgyfed-webmention-like-fediverse
→ 🔮
Post glossary:
backfeed / reverse syndication
https://indieweb.org/backfeed
Bridgy
https://brid.gy/
make what you need
https://indieweb.org/make_what_you_need
manual (until it hurts)
https://indieweb.org/manual_until_it_hurts
original post link
https://indieweb.org/original_post_link
own your data
https://indieweb.org/own_your_data
own your replies
https://indieweb.org/own_your_replies
permalink
https://indieweb.org/permalink
permashortlink
https://indieweb.org/permashortlink
POSSE
https://indieweb.org/POSSE
silo
https://indieweb.org/silo
social media
https://indieweb.org/social_media
static site
https://indieweb.org/static_site
start
https://indieweb.org/start
Webmention
https://indieweb.org/Webmention
¹ https://tantek.com/2023/253/t2/
² https://tantek.com/2010/034/t2/diso-2-personal-domains-shortener-hatom-push-relmeauth
³ https://tantek.com/2023/001/t1/own-your-notes
⁴ https://indieweb.org/discuss
-
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:
https://cosocial.ca/@evan/111237962392745000/favourites
Every step that connects heterogenous #socialWeb systems & protocols feels like progress.
This is day 45 of #100DaysOfIndieWeb. #100Days #IndieWeb #like #likes #fediverse #favorite #favourite #favourites
← Day 44: https://tantek.com/2023/234/t1/threads-supports-indieweb-rel-me
→ 🔮
¹ https://cosocial.ca/@evan/111237962392745000
² https://tantek.com/2023/287/t1/federating-mentions
³ https://tantek.com/2023/289/f1
-
I recently wrote a high level summary blog post:
W3C Technical Plenary and Advisory Committee (TPAC) Meetings 2023
https://tantek.com/2023/262/b1/w3c-technical-plenary-tpac
of my time at the #W3C (@W3.org, @w3c@w3c.social, @W3C) #TPAC the week before.
Posting this note to explicitly #hashtag that article with topics mentioned therein:
#Sevilla #Seville #Spain #WICG #SocialCG #SWICG #Fediverse #SocialWeb #sustainability #IndieWeb #ActivityPub
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.
Post glossary:
article post
https://indieweb.org/article
note post
https://indieweb.org/note
p-category
https://indieweb.org/p-category
tags
https://indieweb.org/tags
-
going to the #SocialWeb CG meeting @W3C #w3cTPAC tomorrow (2023-09-12) at 09:30 CEST.
Looking forward to seeing @evanp.me (@evan@cosocial.ca @evanpro) and many others!
So many advances in #ActivityPub, #Webmention, Micropub, #IndieAuth etc. that it may be time to restart the #SocialWebWG to officially update all our active specifications.
We can & should also reach out to #Bluesky & #Nostr communities to work together on shared semantics and bridging protocols to continue growing a heterogenous #fediverse built on the #OpenWeb.
We know it is possible. We worked hard in the Social Web working group to align a lot of semantics across #ActivityStreams and #microformats2. The fruitful results of that are services like http://fed.brid.gy/ which I myself use to send a Webmention when I make a new post (like this one) and have #BridgyFed automatically federate it via ActivityPub using my personal site identity to #Mastodon followers and others.
@snarfed.org wrote up a recent comparison of top #decentralized #socialProtocols that can help inform a lot of this discussion: https://snarfed.org/2023-09-04_50856
-
If you added a #Mastodon / #ActivityPub follow form to your #IndieWeb site based on Bridgy Fed (e.g. using code/instructions I previously posted¹), you need to update it to add another invisible input element for the "protocol", e.g.:
<input name="protocol" type="hidden" value="web" />
Otherwise people trying to use your form to follow you may see an error from #BridgyFed like:
> Bad Request
> Missing required parameter protocol
Here is the complete example that I posted previously with the new invisible input:
<form method="post" action="https://fed.brid.gy/remote-follow">
<label for="follow-address">🐘 Follow
<kbd>@tantek.com@tantek.com</kbd>:<br />
enter your @-@ fediverse address:</label>
<input id="follow-address" name="address" type="text" required="required"
placeholder="@you@instance.social" alt="fediverse address" value="" />
<input name="domain" type="hidden" value="tantek.com" />
<input name="protocol" type="hidden" value="web" />
<button type="submit">Follow</button>
</form>
I also updated that previous post¹ with the new input in case people find that instead.
This is day 42 of #100DaysOfIndieWeb. #100Days
← Day 41: https://tantek.com/2023/139/t1/wikipedia-supports-indieweb-rel-me
→ 🔮
¹ https://tantek.com/2023/020/t2/bridgy-fed-follow-form
-
One of the pretty neat innovations from #Mastodon has been actual, functional, and fairly reliable (from all accounts I’ve seen) distributed system account migration, with the notable exception of post migration, which has additional challenges worth exploring.
To be clear, as far as I know, no other blogging (or chat) software, system, or even protocol comes close to achieving the level of functionality described in Mastodon’s documentation:
https://docs.joinmastodon.org/user/moving/#migration
In short, moving:
* all your profile information
* moving all your followers & followings, transparently
* redirecting your old account to your new one
More at that link. From the docs, it’s clear that quite a bit of thought & consideration went into the design & implementation.
Once I had setup #BridgyFed to #federate posts from my own site¹, I myself made use of the this Mastodon feature to migrate from my try-it-out @t@xoxo.zone account to my #IndieWeb @tantek.com (move destination handled by BridgyFed).
For me the migration experience was 100%, because I had not posted anything @t@xoxo.zone.
The challenge of post migration is not unique to Mastodon, though I believe it goes beyond “simple” export & import support, which is still a good place to start.
Mastodon has two forms of posts “export” currently:
* RSS feeds, which will get you some number of recent posts, by adding ".rss" to the end of any Mastodon profile URL, e.g. https://indieweb.social/@tchambers.rss
* Activity Streams 2.0 JSON, per https://docs.joinmastodon.org/user/moving/#export (note: it currently says “ActivityPub JSON format”, but there is no such thing, #ActivityPub uses the #ActivityStreams 2.0 JSON format and I’ve filed a PR² to fix this in the docs)
Lots of software & services import RSS, e.g. #WordPress.
As far as I know, nothing (not even Mastodon itself) actually supports importing Activity Streams 2.0.
There is a more complete format (with specification!) for exporting & importing blog content:
Blog Archive Format (.bar), first specified here with example file:
* https://www.manton.org/2017/11/24/blog-archive-format.html
More details and another example file:
* https://www.manton.org/2021/12/27/importing-blog-archive.html
Blog Archive Format has the very nice features of:
* portable HTML feed (h-feed) and JSON Feed
* photos and other media
* locally browsable post archive
Naturally, https://micro.blog/ supports both exporting & importing Blog Archive Format.
There’s an interesting opportunity here for an open source converter
* from Activity Streams 2.0
* to Blog Archive Format
Such a library would make an excellent drop-in addition to any #ActivityPub implementation, allowing both export of posts, and also a browsable archive format, so you could visually double check when importing to another service that these were the old posts you were looking for.
This would be a good first step, using an open standard, towards Mastodon itself supporting post migration³.
Ideally, similar to account migration, the old posts server should also at least:
* redirect old permalinks to the new permalinks
* redirect any replies being delivered by ActivityPub to the new location
* provide #Webmention discovery forwarding from the old URLs to the new URLs (e.g. using HTTP LINK headers)
for some amount of time.
Want to add support for Blog Archive Format or got questions or feedback?
Join in the development conversations: https://chat.indieweb.org/dev
This is day 39 of #100DaysOfIndieWeb. #100Days
← Day 38: https://tantek.com/2023/110/t2/beyond-mastodon-indieweb-own-domain
→ 🔮
Glossary
account migration
https://indieweb.org/account_migration
blog archive format
https://indieweb.org/blog_archive_format
h-feed
https://microformats.org/wiki/h-feed
JSON Feed
https://www.jsonfeed.org/
post migration
https://indieweb.org/post_migration
Webmention
https://indieweb.org/Webmention
References
¹ https://tantek.com/2022/301/t1/twittermigration-bridgyfed-mastodon-indieweb
² https://github.com/mastodon/documentation/pull/1202
³ https://github.com/mastodon/mastodon/issues/12423
-
Two days ago my #BridgyFed followers crossed 8-bits:
https://fed.brid.gy/user/tantek.com
Signs of #TwitterMigration: my prev post had ~2x more #fediverse responses than Twitter, a ~500:1 difference per follower (having ~250x more Twitter followers).
Many possible factors. Mastodon users see more from their followings. Twitter accounts could be mostly bots or abandoned. Recent posts are technical, maybe Mastodon users are more technical. Tech friends migrated first. Or hashtagging #fediverse.
-
#TwitterMigration, first time?
Have posted notes at https://tantek.com/ since 2010, syndicated tweets & an #AtomFeed.
Added one .htaccess line, thanks to #BridgyFed, if you use #Mastodon, you can follow my #IndieWeb site:
@tantek.com@tantek.com
Which demonstrates both the redundancy & awkwardness (it’s not a clickable URL) of such @-@ (AT-AT) usernames.
Like why make me type or show “@tantek.com” twice like that?
Why can’t Mastodon follow a username of “@tantek.com”? Or just “tantek.com”?
And either way expanding it internally if need be to the AT-AT syntax.
Why this regression from what we had with classic feed readers where a domain was enough to discover & follow a feed?
Also, why does following show a blank result?
Contrast that with classic feed readers which immediately show you the most recent items in a feed you subscribed to.
Lastly (for now), I asked around and no one knew of a simple public way to “preview” or “validate” that @tantek.com@tantek.com actually “worked”. You have to be *logged-in* to a Mastodon instance and search for a username to check to see if it works.
Contrast that with https://validator.w3.org/feed/ which you can use without any log-in to validate that your classic feed file works.
Why these regressions from the days of feed readers?
Tantek
All stadeus content and data are available under the