I’m starting to think fedi needs a two-tier follow system.
“follow” as in “I want to see all public posts from that account on my timeline”.
“folllow” as in “I want to actually be a follower and see followers-only posts”.
now we only have 2. but there are valid use cases for 1. that I am encountering both as a follower and as someone others want to follow.
as far as I can tell, there is no reason for 1. to not exist: those posts are public anyway. is it possible and practical at protocol level? is there a way to get the source instance to federate all such posts to the “follower’s” instance despite no “real” follow? no clue. someone who knows activitypub would have to chime in.
as for my use cases: I am posting almost everything public, but sometimes do a more personal post (usually related to mental health) that’s followers-only. I restrict my followers to queer neurodivergent beings that pass my vibe check because that’s the audience I’m comfortable sharing this with.
but there are others interested in less personal things I post and right now they have no way to get those things on their timeline. this is annoying.
sure, I can do multiple accounts. but that feels like a kludge that got carried over as a “solution” from tw*tter instead of doing it right in the first place. also, using multiple accounts is a pain in existing frontends. they implement an impractical paradigm of switching the context of the entire application, instead of presenting a combined timeline. then there’s the entire bullshit with having to boost things from the other account so they reach the rest of the relevant audience and so on. kludge.
@erin usually fedi instances will publish an RSS feed of one's public posts, so using that with a feed reader is a workaround. There are some fedi instances that do a moral equivalent of that (they don't use an RSS feed, but monitor the activitystreams feed). In one patched Mastodon version the functionality is called "subscription".
@robryk do they do it in a way that works well with single-user/small instances “subscribing”? I’ll have to look it up.
@erin I don't see why small instances should behave in a way that's significantly different here, but might be missing something.
They are somewhat controversial, because they allow me to subscribe to accounts that either have blocked me, or whose instance blocked mine.
@robryk if - and that is a significant if - my understanding of activitypub federation is correct, your small instance may not be getting all of someone’s public activity if no one on it actually follows that someone.
@erin it's not pulling from RSS, but rather from the activitystreams feed. (I only mentioned RSS, because that's the option that's easier to kludge together if your instance doesn't do that.)
@robryk oh, ok. thank you for the input and clarification.
I have to make myself a bit more familiar with the protocol side of this.
@erin try requesting urls of various things with Accept: application/ld+json to see how things look like in practice. The correct RFC to start reading is the activitystreams one while breathing in mind that the client to server pretty of it is very rarely implemented (so one can rely on server to server ~only).
@robryk I’m just having the exact same conversation with someone on irc and my conclusion so far is:
it would maybe kinda sorta work only as a source of information on what to request over the activitypub protocol. in other words, if the source server does not federate content to you, you could use rss to request it explicitly.
I see all kinds of nasty impedance mismatch scenarios in any software trying to really be a hybrid fedi/rss reader by pulling data from two distinct sources like this, then presenting it to the user in a way that pretends it’s the same thing.
no actual research on the latter, just a gut feeling of a former systems engineer who was often put in charge of integrating software stacks that were never intended and designed to be integrated. I can smell that shit already just from the description and I do not like it.