There are also a number of enhancements and bug fixes. The most notable changes are:
- Comment boxes will only appear automatically on "Facebook-like" posts (assuming you have permission to comment). They cause confusion and are often misdirected when applied to "Twitter-like" posts, because the author you are replying to may not see a mention notification. Mention notifications are necessary for comments in Mastodon, as that software doesn't have comment notifications. - The Content Filter app has a new rule to filter on the number of hashtags provided in a post. For example the rule '#>20' will filter any arriving content that has more than 20 hashtags.
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.
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.
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 requiring any 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.
Please don't stand on the tracks.
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...
I promise to add some more documentation before this is released, but I just want to keep providing updates on what we're doing here at the streams repository - especially as it concerns the fediverse and conversations.
The background is that we've always provided what I'll call "containerised conversations" in earlier iterations of the fediverse (several years prior to the emergence of Mastodon and ActivityPub). These are quite different from microblogs - which aren't really conversations at all, but more like people throwing posts into space kind of willy nilly. Each post and each comment can be addressed to a completely different audience.
In our alternate implementation of the fediverse, conversations are contained and more coherent. We do this by directing all comments back to the person who started the original post of the conversation, regardless how many levels of nested comments. This person "owns" the topic and is responsible for distributing all the comments to the original audience. This is how one implements restricted conversations - sometimes called circles or aspects - as well as private groups; which are very difficult to accomplish in a microblog platform. This is why only a very small number of fediverse implementations support these concepts.
When we brought our work to the ActivityPub fediverse several years ago, it conflicted with the microblogs, who quickly dominated the space. So we provided some ActivityPub extensions to continue our work and still use these very important conversational constructs.
Fast forward a few years, and we've been squeezed into a corner, and what we consider a superior way of managing "restricted" conversations has been relegated to obscurity. But during this time, a handful of ActivityPub developers have been working on tools which also provide this functionality, in better ways that in our original extensions. So we're updating our repository to accommodate these changes.
This work is described in the following Fediverse Enhancement Proposals (FEPs). The first two deal with signatures and retires the earlier flawed LD-signatures. This allows the content owner to relay private content to other members of the conversation, while providing proof that the author is not being spoofed. HTTP-Signatures don't work in this context because the original author may not have granted third-party permission to access the content directly and may not even be aware of who is involved in the conversation. The audience belongs to somebody else. It is being relayed by the conversation owner who does have permission to access the content directly.
The next two proposals deal with working with contextual collections. In this body of work, every conversation is a collection. Anybody can create a post, but only the owner of a conversation can add a response message to their conversation and distribute it to a pre-defined audience. This is accomplished by turning the conversation into a Collection object.
FEP-400e: Publicly-appendable ActivityPub collections FEP-7888: Demystifying the context property
The end result is that the fediverse is able to support a wide variety of interactions which don't fit in the microblog or 'Twitter' model of interaction. There also may be times when one model works better for some conversations than others. Perhaps a simplified description would be to call these "constrained" or "contained" conversations, and the traditional microblog usage might be called "unconstrained" because conversations and their audiences have no binding to each other. Contained conversations create this binding and creates a conversation as an atomic property in the fediverse. It is also possible to "fetch" this container and access the entire conversation (all activities and comments) across all participants. This is not practical or possible using the unconstrained model. In any case, this is what we're doing. It makes things like the old Google+ "circles" and features like Facebook style private groups available to the fediverse without clumsy workarounds.
And best of all, it doesn't break compatibility with microblog software. It just provides additional functionality and features which that model of interaction cannot provide, as well as allow both mechanisms to co-exist without breaking each other's expectations of visibility and privacy.
Or put in another light, we support all of Mastodon's weird and non-standard privacy modes because we choose to. Some projects do not, and this is permitted by the relevant specifications. This just ensures that everybody supports ours - because we aren't giving them a choice.
I promise to add some more documentation before this is released, but I just want to keep providing updates on what we're doing here at the streams repository - especially as it concerns the fediverse and conversations.
@mikedev It's working. I noticed activities such as Like in my log where HTTP signature belongs to one actor and integrity proof to another. My server checks both signatures, integrity proof takes precedence, the (actor == signer) constraint is satisfied and activity is accepted.
> "We're going to put IMAP on every desktop in America." -- Eric Hahn (1996)
Yeah we did that. I had help.
Today I'm looking at my IMAP (email) feed and thinking that the only thing it has that I don't have in my streams (fediverse) feed is - spam. Why am I still using it? The answer is I'm not really. I check it every few days - and see that it's all spam - and close it again. For the last year everything in my IMAP feed that wasn't spam was notifications of something happening in the fediverse or in one of my code repositories that aren't yet connected to the fediverse. Things that I look at every day anyway. What value add do I get from seeing the redundant email messages? Or more precisely, what unique value does email provide?
That's a really good question. I no longer have an answer.
> "We're going to put IMAP on every desktop in America." -- Eric Hahn (1996)
Gregory's Server
