Items tagged with: streams
@ophiocephalic 🐍 @Tim Chambers @Fediverse Report @Spread Mastodon As a #FederatedSocialWeb veteran and former self-hoster of my own private #Friendica and #Hubzilla instances, I have to say that I can hardly see literally absolutely the whole Fediverse fediblocking #Meta.
You have to keep a few things in mind.
First of all, the Fediverse is not only #Mastodon. Nor is the Fediverse only about a dozen big projects. The Fediverse is dozens upon dozens of big and small projects.
For the whole Fediverse to fediblock Meta, every single last one of them, even just recently launched private proof-of-concept alphas of brand-new projects which nonetheless will federate, will require not only a mandatory instance-wide blocking mechanism, but a mandatory standard blacklist with Meta's instance on it. Otherwise developers can't test-drive their new Fediverse server application without their test instance being defederated left and right for not blocking Meta.
Of course, this would also mean that everything that even only as much as understands #ActivityPub would require such a mandatory default blacklist with Meta on it. Even if it isn't based on ActivityPub. Even if ActivityPub is an add-on, a plug-in, maybe even third-party like in the case of #WordPress. Even if ActivityPub has to be manually activated instance-wide by the admin and then separately by the users for each one of their channels like in Hubzilla's case.
That is, putting Meta on the same list as all other defederated instances would probably be considered not enough. Blocking Meta would have to be hard-coded into the engine of the project itself, also to mandatorily roll it out to all instances of all projects. Instance block lists aren't part of the source code, and if they became that, lots of not-so-techy instance admins would end up with file conflicts they can't solve because the
git pull involved in the upgrade would try to create a file that already exists.
Still, this wouldn't be 100% water-tight. An absolutely mandatory fediblock for Meta would mean certain death for lots and lots of small private instances. Admins of such tiny instances often only do the very bare necessities to keep them running. Sometimes they rarely or never even upgrade the underlying operating system, much less the Fediverse project running on it. Why should they? It runs. And an upgrade means a) a hassle and b) probably more of a hassle if stuff breaks.
Just to prove my point: There are still Mastodon 3.x instances in the Fediverse. There are still a very few running small instances of #Osada and #Zap, both of which have been discontinued on New Year's Eve 2022. These projects are no longer maintained. They won't get any updates anymore. They were superseded by #Streams, and not everyone who still runs these old projects wants to do the switch.
And then there are those projects that are technically still in development, but whose development has slowed down dramatically. Look at how often #Pleroma rolls out new versions. And Pleroma isn't exactly obscure, it has public instances. Or look at #Plume which counts as still actively developed, but whose devs barely find any time to do anything, so it often doesn't get any updates in many months. I don't even think that Plume has any means of blocking instances by blacklist.
So if blocking Meta becomes mandatory, you can fediblock an entire long-form blogging project out of the Fediverse with all its private and public instances because not a single instance will participate in blocking Meta, because not a single instance is even capable of doing that, because the capability is not included and rolled out in time, because the devs can't find the time to include it.
For example, these discussions on FEP c118 here:
# FEP-c118: Content licensing support
Currently, popular Fediverse software does very little to establish the legal status of posts. Controversy over indexing and scraping the Fediverse is common. The hope is that providing a legal framework to express the desires of users as to how their content may be re-used might bring order to this debate.
4. If you don't want your posts being easily accessible on the instances you federate with, why not make the posts followers only in the first place? I'd love to know the history behind folks thinking that public posting and a #noindex or #noarchive hashtag was ever sufficient on the #Fediverse.
Folks with the institutional memory of these things, please step up and tell the history. Every admin has the right to defederate from whoever they want, but to do so on the basis of a #Mastoverse -centric denialism & rewriting of the history of search & indexing on the Fediverse should be called out.
Respecting a federated post's no-index settings or even account level settings would be really cool but is currently impossible across the #Fediverse.
Oh and wait until I tell you about how #ContentWarnings aren't reliably reproducible across the fediverse either. Another day..
FEP-c118: Content licensing support
per activitypub: ActivityPub Activities may additionally be addressed to the special “public” collection, with the identifier https://www.w3.SocialHub
Some thoughts about #fullsearch of federated-with instances. 🧵 1/2
1. Conflating any ill will you have with Supernovae at #Universeodon, with the issue of search indexing on the Fediverse to justify your fediblock won't help resolve the issues around search.
2. It isn't global search. While we shout, lock down, and don't participate in building the additions to our protocols that the #Fediverse needs, we've been letting #Google index the Fediverse. It's already searchable and Google's new Perspectives tab is going to make it even easier. Maybe we could fight that rather than keep thinking it doesn't exist and continuing to write ineffective Facebook-viral style "I do not give permission..." copypasta?
3. The #Fediverse does not respect your do-not-index-my-posts flag. It never has. It can't. It's not supported by the #Mastodon API, as @email@example.com explains, and nor is it supported at #ActivityPub level and will need to be added into a new AP protocol.
Every instance server from the #Misskey (#Calckey, #Foundkey), #Pleroma (#Akkoma), and #Friendica (#Hubzilla, #Streams) lineages has full search of federated-with instances as default. All these services actually pre-date the creation of Mastodon in 2016 you can read @Polychrome@poly.cyber.city 's post for their commentary on such. Fediblock all of them to create your very own #Mastoverse or you could become part of building a better, safer, Fediverse? Perhaps through participating in the Fediverse Enhancement Proposals? #FEP
Does a 'New Facebook Rule' About Use of Photos Start Tomorrow?
"Don’t forget tomorrow starts the new Facebook rule where they can use your photos," the viral posts claimed. "Everything you've ever posted becomes public from today - even messages that have been deleted."Jordan Liles (Snopes.com)
@butter, @Dessalines, I've grown quite fond of Friendica for that very thing, following things, not just people. Not only does it let me follow topics via tags, but things like #lemmy and #guppe get added as "forums", plus I can follow any #RSS or #Atom feed. All of these are added the same as adding any other contact (follow). All of these different ways of following things get listed in the same area of my account, as "contacts", where they can be easily separated into to multiple groups (lists). Each followed hashtag, forum, contact group, or protocol type is always listed down the side of my page where I can simply click on it to filter my current feed.
I know that other #fediverse / #ActivityPub interfaces such as #Pleroma, #Akkoma, #Misskey, #Calckey, #Hubzilla, and #Streams have some/all of these capabilities, each to their own extent. However, having played around extensively with all of them, I've come to find that #Friendica is the one that works best for me. And at the end of the day, this is the only thing that matters. It may be a bit time consuming, but trying all the things is the best (only?) way to see how they'll work for you.
It will depend on the platform. For example, #Friendica (and to an extent #Hubzilla and #Streams), the owner of the group (and anyone else given moderation access) can block accounts. There is also chirp.social which can also block accounts.
Then there is #GNUsocial, which is a rebranded #StatusNet itself a rebranded #Laconica (the first #Fediverse software, c. 2008) have built-in groups feature; which IIRC, can also block users if needed.
Personally, services like Guppe really need to add moderation features, otherwise, what you just described will more likely happen.
@Each Hit Music @Chris Trottier I've started working on a series of comparison tables for the Join the Fediverse Wiki that currently compares the features of
I may add at least #Socialhome and #FoundKey.
I don't know if I'll ever complete and publish these tables, but it won't be anytime soon because it'll be a whole lot of features in these tables. Also, I'll very likely need help from users of other projects to complete the tables.
@Probably Paul 🌍 @maegul @Kevin Davidson @Ada #CalcKey has full #NomadicIdentity?
As in, you can have identical clones of your account/channel simultaneously on multiple instances? They're kept in-sync with each other in real-time? All clones display the same Webfinger ID which uses the domain of the primary instance? And you can make any clone your new primary instance?
Because this is what nomadic identity actually means.
The only projects known to me that support it are #Hubzilla, #Streams and the now-defunct #Zotlabs projects #Redmatrix, #Osada, #Zap, #Misty a.k.a. #Mistpark2020 and #Roadhouse, basically everything created by Mike Macgirvin after #Friendica.
In fact, I've got my doubts that full nomadic identity can be pulled off without having multiple channels per account/login. And this is another feature which the projects mentioned above have and the ActivityPub-based microblogging/macroblogging/"social network" projects don't.
Or are you referring to how easy it is to move your entire account with everything on it from one instance to another? That isn't what nomadic identity means.
Farmer in Bugger All, Australia. Plays a mean guitar, upside down and backward. Communications technologist. Makes the best fediverse software you never heard of.macgirvin.com
@Chris Trottier @Grassroots Joe And I don't know how @Mario Vavti and @mike would react upon the implication that the #Fediverse only consists of #Mastodon and stuff bolted onto Mastodon, including their projects, #Hubzilla and #Streams.
For the record: Hubzilla is from 2012. When Mastodon was launched, Hubzilla had already been around for a whopping four years. AFAIK, Hubzilla adopted #ActivityPub around the same time as Mastodon and not because Mastodon used it. Even when Hubzilla was created, then still being a fork of Mike's own #Friendica and named Red, it had a set of features that outclassed 2023's Mastodon by magnitudes.
So no, Hubzilla is not another Mastodon knock-off, nor has it ever jumped upon the Mastodon bandwagon. In fact, the Hubzilla devs refuse to let themselves be bullied into doing things Mastodon's own, non-standard ways just because Mastodon has the most users and instances.
Also, while Mastodon switched to ActivityPub as its base protocol, Hubzilla stuck to Mike's own #Zot from 2011 which, in turn, has features that many wish ActivityPub had. On Hubzilla, ActivityPub is an add-on, an optional one no less.
@Chris Trottier @Fediverse News Makes me wonder how this will work on anything that's based on #ActivityPub natively. For this reads like it'll first be implemented in #Streams and #Hubzilla. Most everything else doesn't have the same idea of channels.
See, on Mastodon, for example, your account is your identity. If you want another identity on the same instance, you must create another account, a separate login.
On Hubzilla and (streams), your account is not your identity. What's actually your identity is your channel. Each channel offers you at least the same as one Friendica account, but you can have multiple ones on the same account, and each one of them is a separate identity. Even the instance admin would have to do some SQL diving to be able to tell which channels belong to the same account. And if you've got more than one channel on the same account/instance, and you want to switch channels, you don't have to log out and back in.
If you go nomadic, you go nomadic for each channel separately, i.e. each channel can have clones on different instances. Obviously, this requires accounts on other instances. The accounts don't go nomadic, they don't have any content to go nomadic with. The channels do.