And apparently GitLab went down shortly after posting this, so here's an alternate copy: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust...
2,351 karma · joined August 30, 2011
As an aside, this is a big week for ActivityPub, since Mastodon is going to begin rolling out ActivityPub to their ~850k registered users.
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/
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...
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...
And we're even looking at exploring it, possibly, in the Social Web Incubator Community Group: https://www.w3.org/wiki/ActivityPub_extensions#Possible_futu...
BTW, if you're interested in such things, the community group is open to everyone and is hosting weekly meetings https://www.w3.org/community/swicg/ and we'll be hosting a meeting next week https://www.w3.org/wiki/SocialCG/2017-05-31
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.
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!
Includes a great quote:
> 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.
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?
I linked your comment and slides from the blogpost now, btw!
https://web.archive.org/web/20160304070026/http://crawl.develz.org/other/manual.html#n-philosophy-pas-de-faq
The most unfortunate part of all this though is that all these different applications, GNU Social, Diaspora, Pump.io, etc all speak different protocols and aren't all really interoperable. This leads to a "fractured federation", which really isn't great. I've been participating in the W3C Social Working Group to try to standardize federation. Here's our spec, ActivityPub:
https://www.w3.org/TR/activitypub/
Some background: it's derivative of the "Pump API", which is sort of the successor of OStatus, in the sense that the primary author of StatusNet (now GNU Social) wrote the Pump API in response to some perceived shortcomings in OStatus. We've done a lot of analysis to make sure that the protocol can handle all the kinds of things that you expect from the "big player" social networks, but in a federated setting.
Interested? Now's a great time to research and give feedback. We're looking to move to Candidate Recommendation status shortly, which means we're looking for feedback and implementations.
PS: I'm also involved in MediaGoblin, and we definitely intend to implement there. If you're interested in a bit of news from that end, here's a moderately fresh blogpost, including info on how to give your feedback: http://mediagoblin.org/news/tpac-2016-and-review-activitypub...
We're planning on using it for MediaGoblin.
Basically, I think that Lisp and Scheme have a reputation for being unapproachable. This reputation partly comes from how we structure our communities, who we reach out to, and etc. But it also depends on how we message ourselves.
There's a very conscious decision in the new design to make things look playful and inviting, to encourage experimentation. I think that's super important. It seems like it's having some effect on encouraging people to become engaged, and it certainly doesn't seem to be doing any harm to those who are already into hacking parentheses. :)
It's still in an early stage, but it works. That emacswiki post points you in the right direction, but if you use the Guix package manager, you can give it a try: "guix package -i guile-emacs"
Mostly at this point it needs people working on it and playing around with it. Considering you're fairly excited about it, maybe you should give it a spin? :)
http://lists.gnu.org/archive/html/guix-devel/2015-10/msg00916.htmlThe AI Winter is thawing... but whose lap will it fall into after the defrost? Big data mining organizations, or everyday hackers, or....?
Anything above that is written as Hy macros, in Hy itself: https://github.com/hylang/hy/blob/master/hy/core/macros.hy
There's a lot of other core code that's written in Hy itself too. https://github.com/hylang/hy/tree/master/hy/core
I wrote here about why I'm supporting, and why you should too:
http://dustycloud.org/blog/donate-to-conservancy/Re: mirroring, I replied to that a bit here: https://news.ycombinator.com/item?id=6180159
Additionally, you can already host media files with an OpenStack Swift cloud files provider like Rackspace Cloud if you prefer.
I don't know anything about windows or macs personally, though people have gotten mediagoblin working just fine on macs... windows is harder. :) I don't have any clue when that packaging might happen though... if it happens, it'll be by someone else I guess; I just don't know anything about it.