Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

https://staltz.com/an-off-grid-social-network.html

[matrix spec]: http://matrix.org/docs/spec/ [secure scuttlebut]: http://scuttlebot.io/


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.


Do you want server-to-server communication to depend on yhe mercy of spam filters?

Or client-server communication ?


Are you talking about the spam filters that are required for email, or the spam filters that are required for the exact same reasons with ActivityPub?

https://www.w3.org/TR/activitypub/#security-spam

"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."




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: