I'm currently working on 2 issues with the conversation container beta this morning - besides the two I fixed earlier. The first one is vanishing comments from streams release branch and the second is signature validations failing from Hubzilla. Your patience is appreciated.
Have a shop where people would come to me with their supposingly outdated computers and magically turning them into full functionning machines just by installing Linux distros. I could even learn about BSD OSes for that dream to come true.
Was up at 4:30 this morning. Had a half dozen cuppas before 5:00. It's now just shy of 8AM and another half dozen cuppas later.
Working on the groups problem still. Progress has been made and containerised groups are federating. It's frankly amazing what one can accomplish after a dozen caffeine injections.
Groups are even working from Mastodon. I thought long and hard about this and the poor buggers need groups. 8 years later and they're still waiting. Until they get some of their own we'll still be there to help them out.
Time to go out and feed the critters and check the crops. Then I might be able to dig into moderation and bring that up to 2024 standards. We'll see. I already know how to containerise that one - it's just tedious. Worst case is I'll just have to save that for another caffeine-induced sprint. Then I think we'll be in pretty good shape and I might able to move all of this into the dev branch and let some other folks poke at it a bit.
Interesting little dilemma I'm facing with the testing of conversation containers. The parts I'm having the most difficulty with are 1) groups and 2) moderated comments.
Ironically, conversation containers make both of these things a piece of cake. A constrained conversation by definition relays all content to its audience, which is exactly what a group does. A constrained conversation also by definition is a moderated conversation because a comment isn't part of the conversation until it has been added to it by the owner.
So why is there a problem?
Mastodon.
We altered everything we did in bizarre ways a few years ago just to make our consent-driven communications compatible with the elephant in the room. And even though this new architecture does away with all of the ActivityPub hacks and performs the same operations in completely legal ActivityPub objects without requiringany extensions, Mastodon doesn't recognise the entire concept of groups and moderated content. So we'll either need to come up with hacks that make our stuff compatible with their primitive data model, or just say "fugg it" and do it the right way and "fugg them" if they don't want to play in a more capable vision of the ActivityPub universe.
I'm leaning towards the latter. We're creating a better, friendlier, and safer fediverse. This train has been building momentum for 14 years and has no brakes.
It seems to me that working with ActivityPub standards is better than bending stuff to make it compatible with Mastodon. For the moment mastodonians don't use groups, so they won't miss them anyway.
Streams Around 15 years ago, there was a promising social networking app and directory for bloggers that went viral and was completely destroyed by spammers. It was a somewhat unique method of spam attack so I'm going to tell you how you can protect your (streams) site from that kind of thing happening here. Social networks of all kinds are prone to spam attacks if they lack post permissions. This is a problem for large parts of the fediverse, but not so much here at the streams repository. But directories provide another vector. Most fediverse software provides local profiles of people who have communicated with their site. These profiles can be used to launch a spam campaign because there is usually no permission required to be in the directory. If you've ever accessed the site, there is probably a local copy of your profile available to site members or the public
So here are some tools you have available to prevent this from turning into a large problem. The first is to disable public access to the directory unless you have an account on the instance. This is a setting in admin/security. What this does is de-incentivise the payoff for the spammer which is to put their content on public web pages. If it is only available to site members, it isn't as much of a target as a public directory - unless you run a large instance which increases the eyeball count and makes your site a more lucrative target.
The next thing you want to look at is turning off animated profile photos - also in admin/security. This lets spammers play short videos wherever their profile is shown.
These actions alone will help you a great deal. But it may not be enough. I'd like to introduce you to directory censorship, which is available to the site admin. Go to your channel manager (it's in the top menu bar after clicking your profile photo). Now select the "instance channel", which is named after your website. You are now a directory admin. Visit the directory, and you'll find that every entry now has a 'block' and 'censor' button next to it. You can also search for names or other attributes if a site member has reported something specific.
The censor button does a couple of things. The first thing it does is hide this directory entry for anybody that has "safe mode" turned on, so the entry is still there, but only if you have chosen to look at unsafe content. The other thing this does is remove the profile photo and set it to the default (rainbow man unless you've changed this). Use this if you have issues with mild adult content in the profile text or profile photo but you're OK with it remaining in the directory.
What happened with the software mentioned at the top of this article was that spammers replaced their profile photo with animated avatars doing x-rated things. So the censor tool along with blocking animated avatars should prevent this kind of thing without needing to block the entry. But you can also block the entry. Blocking a directory entry while connected to the instance channel hides that directory entry unconditionally for everybody on the site.
Use any or all of these tools as needed to achieve the best outcomes for your site and its members depending on the type of bad actor you're dealing with and your own tolerance levels. If you are lacking any of this functionality, please upgrade. I've been cleaning it up a bit over the last few days.