All the hoopla around the opening of Ikea ...
https://www.rnz.co.nz/podcast/mediawatch?share=72463043-2b3c-40b4-ba16-d8c7d20965c9
... reminds me of the 2004 Czech documentary Český sen (Czech Dream);
https://english.radio.cz/cesky-sen-hypermarket-czech-dream-didnt-come-true-8074451
But the documentary was much more fun.
#podcasts #RNZ MediaWatch #Ikea #documentary #ČeskýSen #CzechDream
Great to hear @rabble doing the lord's work on MediaWatch;
https://www.rnz.co.nz/podcast/mediawatch?share=72463043-2b3c-40b4-ba16-d8c7d20965c9
He mentions diVine, their decentralised reboot of Vine - the original short video app - using the Nostr protocol. In the fediverse we have Loops (or we will when it's fully functional?) using ActivityPub. Then there's Spark being built for ATProto.
It would boost the network effect of all 3 if they interoperated with each other. Before anyone mentions XKCD #927, yes, I'm aware.
(1/3)
A new protocol obviously isn't the solution here. Another possibility is a bridge specifically for short video services. But as with BridgyFed, if it's opt-in it doesn't combine the network effects of the various services, and if it's opt-out the maintainers will be ruthlessly brigaded. By people who neither understand nor care about the difference between interoperability and scraping. See;
https://mastodon.nzoss.nz/@strypey/115681141318257972
It's a wicked problem.
(2/3)
This makes my blood boil; https://cathode.church/fedi-scraper-counter.html No distinction between malicious scraping and people building useful fedi tools, or just making rookie mistakes like that poor ContentNation guy; https://wedistribute.org/2024/03/contentnation-mastodons-toxicity/ No assuming good faith. No fact-checking. No corrections or retractions either, when things turn out to be totally innocent. If I was a employed by DataFarmers to hobble the growth of decentralised social media with dirty tricks, this is the kind of stuff I'd do. #fediverse
Maybe an FEP that explains how to natively publish media over all 3 protocols could be the solution?
I believe Ghost syndicates posts over both ActivityPub and ATProto. I've also heard that Friendica has a module for syndicating posts via ATProto, as well as ActivityPub. There doesn't seem to be much support for interop with Nostr, as yet, which seems a shame.
(3/3)
@evan
> we have bridges for each
Can you expand on "we", " bridges", and "each", in the context of the obstacles I mention here?
A new protocol obviously isn't the solution here. Another possibility is a bridge specifically for short video services. But as with BridgyFed, if it's opt-in it doesn't combine the network effects of the various services, and if it's opt-out the maintainers will be ruthlessly brigaded. By people who neither understand nor care about the difference between interoperability and scraping. See; https://mastodon.nzoss.nz/@strypey/115681141318257972 It's a wicked problem. (2/3)
(2/2)
Bridgy is limited in its usefulness by being opt-in. Despite - as you've pointed out - theoretically enabling us to federate with the ATmosphere as if it was one big AP instance.
Mostr instances aren't limited in that way, but don't bridge with the ATmosphere. Also likely to be blocked by Loops, so that @dansup doesn't get brigaded by the Mastodon HOA over irrational fears of second-degree social contagion 🙄
(1/2)
@evan
> I think they can both bridge through AP?
Like, diVine > Mostr > Bridgy > Spark, or vice-versa? That might work if Bridgy was opt-out rather than opt-in. Or if Mostr admins can somehow do the Bridgy opt-in dance for their instances.
But even if all that were to work, then there'd be 2 SPoF between the 2 accounts trying to interop, instead of just one. This is an ugly hack at best. Not infrastructure.
(2/2)
What would be much more futureproof is standalone federation components for each popular language/ framework used in web and app development. Plus any others people care to write and maintain.
Providing any app that plugs in the appropriate component with native support for; RSS, ActivityPub, ATProto, Nostr, and any other social syndication protocols in active use. Bonus points for supporting any legacy protocols still in use, like Diaspora and the pump.io API.
(1/2)
@evan
> It's too much effort for developers
That's why I'm advocating for ...
> standalone federation components for each popular language/ framework
Implementing AP from scratch is too much effort for most developers. e Especially if you want it done well, and consider the risks of getting it wrong;
https://wedistribute.org/2024/03/contentnation-mastodons-toxicity/
Much better to have federation protocol specialists maintaining plug-in components as shared infrastructure.
(2/2)
Also, it can't be worse than relying on the string telephone of bridges described above. Imagine how that would scale if everyone using IntsaGrim and TikTok migrated to Loops, diVine and Spark. It wouldn't.
@evan
> They should develop for the open social networking standard
Sure they should. Are they? Will they? You know as well as I do that we have to engage with the net as it is, not as it would be in our perfect world. That's why SWF takes DataFarm money, right?
Strypey
Evan Prodromou