We did reach out to both all the major centralized social networks and also all the distributed social networks. The major social centralized networks didn't seem interested in participating in this round, but they were welcomed and encouraged to become part of the group iirc.
Well we certainly consider it an important aspect! But also, as said, we were standardizing the existing set of federation functionality currently implemented in the federated social web.
But the Social Web Incubator Community Group has made anti-spam/anti-abuse stuff part of our mission, but that's hard stuff. ActivityPub does include federated blocklist support, but I think it's not enough. I've written about possible directions though: https://dustycloud.org/blog/possible-distributed-anti-abuse/
It's tricky, though people are using them. Mastodon probably is seeing the most success at the moment. Over half a million users by current estimates. Not everyone who signs up stays around, but there's still quite a bit of retention. We could do better.
We need to make these things easier to host and deploy though. Having worked on MediaGoblin for many years now, I've found the most depressing part of it is that not only is it hard for people to start hosting things, it's even harder for them to keep it running... and it's not just MediaGoblin; you'll find this of most social network things. Most especially, people become afraid to upgrade their systems. I'm hopeful that systems like Guix will help in that regard, but that's a whole direction to explore itself: https://media.libreplanet.org/u/libreplanet/m/solving-the-de...
So, I'm co-editor of the ActivityPub spec, hi! And yes, there's both reasons to want a Delete operation and to be skeptical of it!
Reasons to be skeptical of it: well there's the obvious ones, you might want to hold on to some content coming your way and lots of people are disappointed to see things disappear. Mutating networks have some dangers for sure.
Reasons it to want it, or that it's there: well, this is how all the existing federated social networks work. ActivityPub was designed in the context of standardizing basically something that projects like Mastodon, Diaspora, MediaGoblin, GNU Social, etc can use. And that is how things work now... mutation and federated deletion has been part of the existing federated social web for a decade. And we're trying to build something people can hook into their existing systems. People may also change their minds about things. Should they have the authority to remove their own posts? An open question, but at the very least, whether a server removes the content or not, a Delete is a request to do so across the network.
However, yes, there is an alternative structure one can imagine for these things, and that's something a bit closer to something git-like in the way that branches point at commits, but may change at which commit they point to over time, but the commits themselves never change. That's a desirable thing to explore, and I've blogged about it: http://dustycloud.org/blog/an-even-more-distributed-activity...
There's a public delivery mechanism where if many people are on the same server, and its a public post (eg Twitter style messages, etc) it can be delivered to a shared public inbox https://www.w3.org/TR/activitypub/#public-inbox-delivery
That way the receiving server can only get POST'ed to once and distribute to the appropriate followers.
Of course, for more limited distribution posts, you still have to distribute individually, but that's no different than how email works.
Hi, MediaGoblin co-founder and co-maintainer here.
It's still under active development, though I've temporarily handed over the reigns to others while I've been busy getting the federation standard we're going to use nicely shaped up through the W3C spec process https://www.w3.org/TR/activitypub/
That's taken up more of my last year (okay, last two years) than I expected. I'll be back in the swing of things within the next few months. We have a federation branch right now, but the standardization process of ActivityPub meant that we're going to have to retool some things before its released in 1.0!
The good news is that ActivityPub is looking to be picked up by projects like NextCloud, Mastodon, Pump.io, and quite possibly GNU Social, Diaspora, postActiv. This means we should be able to have more federation working across the many federated social web projects out there.
If you're interested in ActivityPub and federation generally, I highly recommend checking out the tutorial, which is baked into the spec: https://www.w3.org/TR/activitypub/#Overview
In the meanwhile, Boris Bobrov (breton) has been kindly doing the main work along maintainership while I've been preoccupied. But, I'll be back soon... and it'll be good to be back!
I've skimmed over the activitypub overview. It looks interesting. I'd be curious what your thoughts are on it in comparison to two other "recent" decentralized social protocols.
I feel it shares a lot of similarities with the [matrix spec], though obviously a different vocabulary. Also, matrix is focused a lot more on the concept of subscriptions and eventual consistency.
The other recent protocol I'd associate this with (loosely) is [secure scuttlebut]. This uses an append-only log, which users can subscribe to. The protocol lets applications on the same network locate each other and synchronize logs, or they can connect to a pub server which helps with providing more permanence and crossing network boundaries.
The latter example is much closer to what I'd like to see in a decentralized social web. You build a self-hosted stream of public and private messages, and those that are subscribed (individuals or pub servers) replicate a copy of that stream. If individual pub servers go offline, others will have duplicates and users will be able to continue receiving your updates.
Granted, this setup has some serious issues when you consider abuse. Pub servers currently have no concept of filtering and any approach to that would raise concerns about censorship. I'd also like to see the clients move to a browser based, port 80/443 setup, where perhaps someone can run a self-hosted pub server and web client on a cheap vm somewhere. A sort of web proxy that mobile/desktop clients can sync to. The clients in this scenario would not speak scuttlebut directly, but rather post messages to the web server, which would manage injecting those messages into the ssb log.
I can't figure out what advantages ActivityPub has over email. It seems to just be a way of sending messages to one or more recipients. Email already does this. Couldn't you just stash that blob of JSON in an email body? That way, no new servers would need to be set up; everyone already has an email address.
"Spam is a problem in any network, perhaps especially so in federated networks. While no specific mechanism for combating spam is provided in ActivityPub, it is recommended that servers filter incoming content both by local untrusted users and any remote users through some sort of spam filter."
> Sometimes you would like to evaluate code that comes from an untrusted party. The safest way to do this is to buy a new computer, evaluate the code on that computer, then throw the machine away. However if you are unwilling to take this simple approach, Guile does include a limited “sandbox” facility that can allow untrusted code to be evaluated with some confidence.
People are I hope aware of the ability of abuse reporting systems to themselves become channels of abuse. Facebook's real names policy is exploited by anti-trans campaigners to force people off the platform, for example. Anyone should be aware of the risks of automated threshold systems being abused: if all you have to do is get 100 accounts to press "report abuse", that will be abused very quickly.
Local standards also present problems. Do we really want to go along with e.g. Pakistan arresting people for blasphemy?
It's definitely true that anti-abuse systems can be themselves abused, though most of the systems that you're talking about are partly due to the anti-abuse systems being centralized, right? I also see a lot of comments here along the lines of "but that's censorship!" But the article is discussing decentralized anti-abuse systems which allow individuals to set up their own opt-in filters which apply to themselves and their communities (which means different people might have different filters). Do you think that's different?
Filters deal with the situation where A is sending to B something that B doesn't want to recieve.
The situation where A is sending to B something that's harmful to C cannot be dealt with by C's filtering and can only be addressed at a higher level in the system.
Those are the technical distinctions, but there's a lot of possible things covered by the second case: leaked nudes, lynch mob organisation, slander, leaked intelligence, compromised party documents, names of human rights activists being leaked to secret police, copyright infringement, child porn, fake news, real news in fake states, allegations that invitations to pizza are evidence of child porn, and so on.
Other things covered by this case include leaks identifying corrupt behaviors, allegations of sexual harassment such as Susan fowlers, and evidence of human rights violations that the authorities wish suppressed.
Or various right wing ideas now softly suppressed on Twitter/Reddit.
>The situation where A is sending to B something that's harmful to C cannot be dealt with by C's filtering and can only be addressed at a higher level in the system.
Huh? If C knows A's public key and the content is signed, why can't C filter A's content?
That's great to hear that the Matrix community cares about this so much, and is thinking along similar lines! (The fact that you're already exploring the Stellar approach makes me feel a little bit less crazy for thinking some of these things.) I agree, I hope we can work together... it really does face everyone in this space.
I linked your comment and slides from the blogpost now, btw!
If you've never tried DCSS, I think you should try it. I think it also mitigates a number of the same things you complained about. The game's built-in manual has a whole section about its game philosophy you're likely to find appealing, especially if you were frustrated with Nethack for those reasons:
