Hi, this me from my Friendica instance. I also post from @GidiKroon@mastodon.social, @gidi@pleroma.gidikroon.eu as well as from Twitter, Instagram and Tumblr as @GidiKroon but I'm mainly using my own Friendica for now. Even though I have been on the fediverse for a few years, I've never done an #Introduction post, so let's do one for this channel.

I tend to post about actresses and singers I'm a fan of, sharing news about their new projects as well as my thoughts about films and tv I watch. In between I give my take on political things as well as about the fediverse. When I learn new things hosting a fediverse server or other technical things, I try to share them here too. Longer posts may end up on my blog gidikroon.eu (which you can follow at @GidiKroon@gidikroon.eu).

In real life I work as a software developer, but I keep work separate from a private account like this. I play (beach) volleyball when I can, at a very low level. I live in the Netherlands and occasionally cycle and take photographs. I read and watch sci-fi and fantasy, and am interested in ways to achieve social justice, gender and race equality, sustainable energy use and climate justice.

Feel free to follow, as I will also follow other accounts I find interesting without expectation of them following back. Feel free to share (boost, repeat) my posts if you want, using whatever share function comes with your platform. I tend to close DMs to only allow people I follow. I check my fediverse accounts only one or a few times a day, typically on my phone or tablet, so I tend to not be part of live discussions.

Ideally a lot more things on the fediverse would be 'approve upon first use' instead of 'auto-accept'. Admins should approve signups, but also an account's first post should go through an approval queue. PeerTube already has this. These could all be really quick approvals without much thought, but at least it's a threshold.

What does this do? That small forgotten instances automatically stop sending. They don't turn into spam-relays like now.

Also on the incoming side any new domain should get in a queue, which an admin can once a day mass approve before federation is possible and the queued posts are placed in the timelines.

For each new unknown account on a known server the same thing should happen. Posts are queued until an admin approves, unless the known server was marked as trusted due to having a controlled sign-up process.

What does this do? It means that admins of small instances can go to bed letting a server just run. Existing connections can keep communicating, while spam and block evasion can't happen and their users are safe. Just that new connections will have to wait a bit.

Also, each first interaction between accounts needs to be approved by the receiving account. Receiver will not get notifications, and can always revert this decision. This way any spam, harassment, etc, is sidetracked to an easy to ignore side-queue with easy mass-deny functions.
#fediverse #spam #antispam

What I do think are the main good things about the #fediverse and #Activitypub (and I don't think the often-cited lack of algorithms and no-data-harvesting are the key things):

• ability to choose your host and its set of rules (different things are important to different people; you can select a server that matches your values. It isn't about more or less moderation, it's also different kinds of moderation)
• ability to self-host (e.g. if you want to post a lot, maybe a lot of videos, you may find it problematic if someone else bears the burden of the storage costs. With self-hosting you can do what you want without guilt) (it was recently pointed out that organisations can host on their own domain, providing an alternative to a blue tick verified account system)
• mix of different types of platforms (you can follow and reply to videos on a YouTube-like service, or photos on an Instagram-like service, with your Twitter-like account)

Why is better privacy and no algorithms, and no ads, not the main advantage of the fediverse? Because that's just the current culture. There's nothing technically stopping someone from having ads on a server, or introducing algorithms for top-posts, or collect usage data. We just collectively don't like people who do that, so no one is likely to do this anytime soon.

Things I think don't work well or at all in #Activitypub (the protocol behind the #fediverse), due to limits of the protocol or the used vocabulary:

• Being able to control replies (who can reply, which replies are visible; some platforms suggest control of who can reply but you can't really prevent people from replying on other platforms)
• Controlling who can see your posts (you think you control this, but you don't; once the post is on another server, they could theoretically show it to anybody) (similar to how on Twitter when you block someone, they can just log out and see your posts)
• Hashtags (they don't work like you think, are used to, or how they should work)
• tumblr-style reblogs (something between a reply and a reshare ('Announce'), sharing a whole thread on your feed while adding to it at the bottom, and increasing the 'notes' count on the original post)
• Twitter-style quote-tweets (there's no verb in the vocabulary to notify the origin server about the post being linked, so a quote-share isn't quite the same)
• View counts (#PeerTube shows how often a video is viewed, but this is for viewing inside PeerTube only; many more views may be via other means)
• Having images in posts (of course there are images in posts, but they are not really 'in' the posts, they are retrieved separately, but this is a bit of a nitpicking distinction only interesting for server load vs privacy)

Weirdly, a common problem in fediverse platforms is that user profiles from other servers aren't complete (not showing all posts), but that would totally be possible in Activitypub by using the outbox collection. Not sure about replies under remote posts though, they often are incomplete as well but I don't know whether there's a 'replies' collection.

Other things that currently are problematic but have nothing to do with limits of the Activitypub protocol (but some with the choice of using webfinger for account names) and are likely solvable:

• finding users (only local users, and locally known users, are easily found with a search)
• finding topics (idem, a topic could be very popular on other servers but if nobody on your server was ever @-mentioned you'd never know it)
• share identity between platforms, or not have the domain name in your handle (or actually changing your handle at all is currently not possible)
• search within your server for posts based on text (#Mastodon limits search deliberately, other platforms don't)
• not having your server crash when someone with more than a few followers reshares your post (currently all receiving servers go and request the post's contents and we all forget to cache this stuff)
• not having a small website crash if it's linked in a post (currently all servers individually contact the website to construct the preview card; there's no central preview card cache, nor is the preview card generated on the sender side as it should)

The often mentioned related issue of having your accounts on multiple servers of the same platform is solved, however. On e.g. Osada you can having a nomadic identity and switch between hosts without losing posts. Most platforms don't implement this, though.

Example of the unexpected limitations of Activitypub: let's say next year some conference about some topic X is held and they ask everybody to use the hashtag #XConf2023. They see only a few, or no, posts. What happened? Because Activitypub only includes hashtags in posts that got delivered for some other reason, as long as no local user was @-mentioned, the posts do not get delivered to the server they were listening on. Activitypub lacks the ability to address (or subscribe to) hashtags.

To solve many of these problems, we'd need several types of directories, relays or caches and more adoption of the ones that already exist. Also the work towards #ocap (object capabilities) is useful to put the poster back into control of their post.

Am I missing the mark? Missing something else?