concept of federated cooperation on instance allow/block lists
I'm writing in note-form because it's mostly for myself, but I'm open to discussion or elaboration.
Each participating instance maintains two lists:
* explicit allow list
* explicit block list
Each list is optionally public, allow-list-only, or more restricted
When an instance meets an unknown instance, the admins are shown which "allies" block or allow it, and can choose to "allow", "block" or "do nothing"
What about social media algorithms that we can actually understand and tweak?
Imagine "sorting" your timeline to show posts from the last 48 hours, and put posts from the accounts you interact most with on top.
Interaction levels could be chosen to be measured by median time between interactions in the last 14 days.
Hot take: Social media should have an easy and clear functional distinction between "this should be shared widely and spread to word-of-mouth" and "this is meant for my network, whatever that means in this context".
And it should be independent of technical security measures such as "public/instance-only/followers/direct" privacy levels.
I'd love to read/make an analysis of why danes generally use microblogging so little, yet are very fond of instagram and various blogging sites.
I know shit about how and why danes use social media, though, and I Do Not have the resources to pull off a comprehensive survey.
Maybe I could try the waters with a Google-forms-like questionnaire? I'd "just" need to figure out how to word the questions and what to ask for...
Hot take: Having good, safe & useful defaults means social media accounts should be "locked"* by default. Auto-accept followers should be opt-in.
* i.e. require explicit approval of followers.
#SocialWeb feature idea: opt-in warning before replying to someone that doesn't follow me.
(Or someone that I don't follow, or someone that's not a mutual, or other similar "have we communicated before" criteria)
Ceterum censeo "Like Buttons" esse delendam.
#SocialWeb feature request: disable fav and boost notifications for non-mutuals / people I don't follow.
Lite variant: Collapse them to a single notificiation (e.g. "30 strangers boosted your toot")
Social Web, luke-warm take, content filtering
Content filtering that depend on putting more work on the content authors is never complete.
For multiple reasons:
1) Bad faith authors: misusing metadata to force noise through the filter (e.g. # MastoDev )
2) Low spoon authors: opting out or forgetting to use metadata (e.g. missing image descriptions)
3) Apathetic authors: outright not using a feature because it doesn't impact them (e.g. not using content warnings at all)
Nudging towards accessible behavior is good
#SocialWeb idea: tiny "status" icons next to every post that explicitly show whether the media content of the post has an image description. Making it more visible when an image description is missing is one way to nudge people into actually writing something in the image description field when posting. And makes it easier to choose to not boost undescribed images.
(Another way would be to always show image description input)
I should take this premise and write a blog about "silos vs private forums" and why one is big, the other is failing and both are extremely limited in their usefulness.
Unfortunately, I'm also inclined to postpone it to "when I have time" also known as "never" or possibly "when my toddler is old enough to move out".
Social media hot take
Likes (👍's / ⭐'s / ❤️'s) should be a signal from the liker to the likee, and should never be displayed publicly by the UI.
I'm unsure whether this is a good hack or not, and it's might fall under misuse of AP semantics in a way that I've personally ranted against, BUT...
A method of having "channels" / subsets of an account being followable, by making dummy accounts that auto-boosts anything the parent account posts in that category. It would definitely need support from both client and server software, but other federating servers could still use it without explicit support.
Imagine an ActivityPub server that gave all it's participants a vote to decide whether to federate with a new server, whenever a new server tried to interact in any way.
Bonus points: forcing follows from that server into pending until the federation permission is voted on.
Bonus points: opting out of such votes, to avoid having to consider new servers and trust the rest of the community.
On follower interfaces; group by domain
Instead of a raw follower list in chronological order, federated social media could (should?) have the list sorted by instance name, so it'd be easy to get an overview of where one's posts are automatically federated - possibly including a notice for any relays one's home instance sends public posts to.
And it should be possible to auto-accept follows from a whitelist of domains, administered through the same interface.
I want to be able to boost a thread.
Let me pick a beginning (start-toot) and an end (stop-toot), and make a single boost that signifies "this is a thread you should read".
This can both be used for boosting _a conversation_ (instead of boosting individual toots), and it can be used to boost (insightful, interesting, fun) monologues or fiction split over multiple toots.
As a principle, I want more focus on threads and conversation in UI design, instead of "everything is one toot"
I took a toot-thread from last year and turned it into a blog post:
It's about what types of interaction thrives on microblogging platforms, and it can be read as a precursor to my thoughts about why microblogging as a concept is slightly toxic.
Unfortunately, the latter blog post is currently unwritten, so y'all will have to make do without it, for now.
Jeg får aldrig nok af rumskibe, never, ever, ever.
Parent, Feminist, Softwaremaker
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!