ActivityPub Could Be the Future | Hacker News Reader

ActivityPub Could Be the Future

kyefox.com

134 pointsrapnie69 comments

ActivityPub isn't the future.

Useful things that are built, brought to market, and meet user needs that may happen to use ActivityPub under the hood are the future.

Knowing what is useful for whom and how to bring it to market in a sustainable manner for the people it's intended for is a super critical element. One that's often overlooked.

Specs are like plumbing pipes. People care about sinks, showers, and stuff like that. The pipe fittings, materials, and sizes enable a lot. But, it's not what the end users tend to care about.

I wish more developers understood this very basic concept instead of introducing layers of unnecessary complexities in the specs and plumbing that don't necessarily improve a sink or shower "for the better".

If you're installing lots of sinks and showers, it's OK if you make the pipe fittings, materials, and plumbing a bit easier to work with. Coming up with dozen of all all new sets of pipe fittings, materials and plumbing designs every other week doesn't make installing sinks and showers easier.

Imagine walking into Home Depot and discovering there are about 100 'standard' styles of sinks, faucets, fixtures, pipes, fittings, etc. all with varying degrees of support from none to complete for interoperability. Not only that, every other month, 10 of each of those pieces are no longer manufactured or supported and 20 complete new designs are created with all the same cavets as before.

Meanwhile, you install these sinks daily and the customer really doesn't care at all about how elegant the back pieces are from a mathematical or structural view, they just want a functioning sink that they can assume is easy to fix or replace parts on when it breaks. Not only that, they want to be able to call any plumber and have that done without the plumber spending 2 weeks just figuring out what the hell the previous plumber did before they figure out just how to fix it. At which point they decide its easier to just rip everything out, set it on fire, and pick the latest sets of pipes and fittings for no necessarily justifiable reason than it will cost more in time and effort to deal with the previous sink install than to start from scratch.

Just this Sunday I used an M5-sized drill bit from one manufacturer, in a drill from a second manufacturer, and the hole that I drilled was EXACTLY the right size for my M5-sized bolts from a third manufacturer.

After recently spending three whole days trying to make one part of Kubernetes talk to another part of Kubernetes (and eventually giving up), that brought me so much joy that I’m wondering if I should give up on software and get into carpentry full-time...

> Imagine walking into Home Depot and discovering there are about 100 'standard' styles of sinks, faucets, fixtures, pipes, fittings, etc. all with varying degrees of support from none to complete for interoperability

[severe emotional trauma flashbacks to previous contracts]

I've seen some heroically constructed Gaudi-esque crystal cathedrals of systems and every one of them could have been replaced by a toolshed and done the same job.

On the other hand, the metaphor's a little weird because... If there are EZ-use fittings that simplify certain use cases, I, a construction-minded person who doesn't usually engage in plumbing, may decide to create something I wouldn't have otherwise. Then that thing might get adoption because what I brought to the table was Super Cool And User-Relevant. The EZ-use fittings enabled that thing, even if they didn't define it. See: all the Big Things that started on shitty but accessible tech frameworks.

As an IndieWeb participant, I find the ActivityPub-verse confusing. Perhaps one of you can help me understand.

At Southern California Linux Expo, I joined a discussion session to learn more about ActivityPub and the Fediverse. What I took away is that the flagship apps supporting ActivityPub are designed to cater to people who want a single app for each type of social media interaction that they have. One app, e.g. Pixelfed, for posting/looking at photos like Instagram. One app, e.g. Mastodon, for posting/looking at text notes or articles like Twitter/blogging. When each of these apps implement ActivityPub, it becomes possible for people to communicate across apps. (Presumably there's one for music listening...)

I understand the drive toward cross-app communication, but I don't understand the "one app per use" way of thinking. Perhaps it's because I rarely use FB and have never used Twitter/Insta/Pinterest. To the extent that I want to broadcast my online social activity at all, I want to do all my posting with one UI, in one place (i.e. in one "app", my CMS) , and I don't care whether someone looks at my stuff by reading my website or subscribing to my feed. I think if someone just wants to see photos, or articles, or "tweets", or whatever, why build a separate app? Why not just filter the incoming content?

Running e.g. a Mastodon instance requires someone to administer the server. Once that's in place, a community can grow up on that server. This seems to mimic more traditional web forums. Is that part of the draw? A central meeting point for your community -- with ActivityPub letting you use your identity in that community while interacting with people from other communities?

IndieWeb and ActivityPub can play well together. I for example am part of the IndieWeb using my blog. But my blog also supports ActivityPub, so that people can follow it using Mastodon for example and ActivityPub replies get translated to webmentions. However, it's a very custom implementation and I need to figure out how to make it available for use by more people.

Probably the easiest way to participate in both the IndieWeb and the Fediverse is by using Wordpress with a couple of plugins installed.

To me this isn't too strange. Sure it's different but the alternative is our current system where each single social network implements its own video player when it grows big enough.

I'm still trying to understand ActivityPub / Fediverse completely, but once you manage to make several social apps use the same underlying protocol then the app just becomes an interface and the protocol runs the social network. And just like how a file system has various kinds of tools to interact with different kinds of files, it's not odd for a network of shared 'things' to have several tools to interact with different kind of things.

In theory the app just becomes the interface and the protocol runs the network, but in practice the implementations are hooked on the idea of being in control of the entire experience, and the app runs the protocol. Also, ActivityPub seems to be more like a vocabulary—apps then use their own data models, extensions, restrictions, &c.; some compatibly (e.g. Pleroma/Mastodon), some not. And from what I’ve seen, if I want to host several apps, each has to be on its own domain. Perhaps this is not a fundamental limitation (I don’t know), but it does seem to be a de facto limitations. I don’t want to host Mastodon at x.chrismorgan.info and post as me@x.chrismorgan.info, something else at y.chrismorgan.info and post as me@y.chrismorgan.info, &c. I want to use one identity across all the apps, and be me@chrismorgan.info for whichever app, which would then match my email address.

> once you manage to make several social apps use the same underlying protocol then the app just becomes an interface

Thanks, contravariant! This was the key idea I was missing.

From what I've seen so far, Activity Pub does allow multiple apps per use so individuals can choose an app of their liking. For example, I'm using Pleroma instead of Mastodon and the interop with Mastodon instances has been seamless. It's early days exploring for me, though.

This issue of bridging the IndieWeb and the Fediverse is fascinating. I'd think it would be more naturally collaborative, but there's a lot to sort out yet.

I think that if you did use different corporate social media, you'd see that the different features encourage very different kinds of use. Instagram is the way it is, for instance, because even if what you want to post is a whinging paean to your ex, you have to figure out a photo to go with that in order to put it on your profile. Even if what you want to post is a text meme from Tumblr, you've got to screenshot it, and now other people can swipe that screenshot. The way people respond to restrictions on use creates new forms and modes of use; new platforms emulating old ones makes sense.

> The way people respond to restrictions on use creates new forms and modes of use; new platforms emulating old ones makes sense.

Thanks, that helps me understand.

Can anyone explain, in simple terms, how interoperability and migration works with ActivityPub (or point to resources that do)?

If I create an account on a Mastodon instance, and want to move it to another instance, do I lose everything?

And how does integration among the various platforms currently out (e.g., Mastodon, Plume, Pixelfed, etc) actually work? Is there some tool to see feeds aggregated from all these implementations? Or does it work differently?

I ask these questions as someone used Mastodon for a bit, has explored a handful of ActivityPub implementations. It all sounds very cool to me, but I still don't quite "get it".

Personally I prefer the approach of Secure Scuttlebutt, but I realize their P2P workings are probably unrealistic and impractical for the vast majority of people.

I want to see a hybrid federation/p2p approach (Secure Scuttlebutt pubs/rooms are close this). As far as I understand it ActivityPub is just a standard for interop between social network services. The social networks still own your data and while they do offer tools for migrating between them you are still essentially at their mercy. You could run your own instance but you'll run into the same problems as you would running your own email server. Not every one will have to ability to do that and you could still run into the 'gmail problem' where large instances refuse to federate with small user instances.

It would be cool if there was a protocol that was fundamentally p2p but with a federated 'tracker' layer that is basically indistinguishable from normal social media sites to casual users. The social media sites would help propagate the content and if one went down or refuses to track your content you can just peer with another one (or just continue to share content with your personal network of followers over a gossip protocol like SSB without the need for a tracker)

ActivityPub can be used in a P2P situation. The biggest problem for that right now is that we use DNS for finding other instances, so you will need something with a domain name.

Thanks! I would like to know if there are any projects working on this. I found this thread discussing how it could be done over SSB

https://github.com/ssbc/ssb-db/issues/202

> If I create an account on a Mastodon instance, and want to move it to another instance, do I lose everything?

You can send a `Move` activity that will tell other instances that you moved, so people will (depending on their server) refollow you automatically. We (= people working on ActivityPub systems) are thinking about ways to create identities that don't belong to any one server, so you wouldn't lose your account even if your server went down.

> And how does integration among the various platforms currently out (e.g., Mastodon, Plume, Pixelfed, etc) actually work? Is there some tool to see feeds aggregated from all these implementations? Or does it work differently?

In general, systems display what they can. Pixelfed, Mastodon and Plume mostly send `Note`s and `Article`s around, which are easy to display in any of their respective interfaces. Other types like `Video`s will usually be displayed as good as possible, with a link to the originating instance. Unknown activities are usually just thrown away by the receiving server.

> ...systems display what they can. Pixelfed, Mastodon and Plume mostly send `Note`s and `Article`s around, which are easy to display in any of their respective interfaces. Other types like `Video`s will usually be displayed as good as possible...

(Not the person you replied to) Thanks, this was helpful. The fact that there's a common activity vocabulary helps me understand the usefulness of an ecosystem of ActivityPub apps which focus on different ways to write and view posts.

Thanks! Integrations don't sound perfect, but I guess it would be unrealistic to expect perfection given the nature of the implementations.

Identities that could be somehow owned independent of servers would be a game-changer, I think.

Thank you for your work, and congratulations on 2.0 ;)

From what I've been able to ascertain, it's just not a _thing_ unless you want to roll-your-own migration tool. There's a few-years-old issue that's now closed: https://github.com/tootsuite/mastodon/issues/177 but links to this currently open issue, which mostly reiterates that this is problematic for a number of reasons: https://github.com/tootsuite/mastodon/issues/12423

From what I understand, it's fairly trivial to post to _multiple_ ActivityPub accounts, but true _migration_ just doesn't exist per se.

You can move between Mastodon instances, but you will lose all your posts https://docs.joinmastodon.org/user/moving/

You can't import your posts, but they will still exist at your old account: if I move from foo@social.example to bar@social.example, then all the posts I made as @foo are still visible on @foo's timeline, rather than getting moved to @bar. (You would have two copies of all your posts otherwise, since people can still fav/boost/interact with the post made when you were still @foo.) Moving accounts will redirect your followers to the new account, and you can import all your old follows/likes/&c to the new account.

Also, you can still export your own posts to preserve them. You could even use that to reimport them (just as said without the ability to migrate faves/boosts/replies/other interactions).

The email analogy isn't always great with ActivityPub federation, but it's still a useful analogy as email is our most common federated service, and here ActivityPub migration is no worse than email address migration, and certainly at this point in some ways already better (follower migration is something email could have used; updating your email contacts list is still a very manual process).

Looking at a protocol such as ActivityPub is actually the wrong analysis and will mislead you with false hope. I'm not against decentralization but if we techies want to raise the bar discussing realistic outcomes, we need to break out of the unproductive loop of focusing on technical protocols.

I'll copy&paste a previous comment here:

>We need a protocol, a specification for completely decentralised, carry-with-us social networks.

I know it seems logical that a "social network protocol" is the answer to replace Facebook but after studying the mechanics of social networks, I've concluded that focusing on technical protocols is incorrect.

My suggestion to programmers seriously thinking of new solutions in the social networking space: don't get sidetracked into thinking about the protocol because if you do, your new social network will end up in the graveyard of previous failed projects like Diaspora. Instead, think about the database of real names.

Also, another previous comment on how focusing on protocols is (inadvertently) analyzing the wrong drivers for success: https://news.ycombinator.com/item?id=20231960

Another comment explaining why the free protocol "Signal" didn't solve the funding dilemma: https://news.ycombinator.com/item?id=20232499

My previous comment on why protocols like ActivityPub & Mastodon are not the answer for a general purpose social network adopted by the masses: https://news.ycombinator.com/item?id=18727230

People reasonably want to separate what makes Facebook useful for users from what makes it profitable for Facebook, because the part that's good for FB is bad for us. Facebook does not care who they harm by selling their information or analysis of, as long as they don't harm themselves in doing so.

The broader problem we're having and trying to solve is centralized power that is hostile to ordinary people. The internet could have been an even more democratizing force, but economic and political pressure have made it largely another tool of oppression and concentration of power for those who hold power.

A protocol can't fix that alone, but it is a piece of the puzzle to answering "How could we do this better?" It's a piece which is more accessible than overhauling society to eliminate incentives to sell out people's privacy, freedom and autonomy.

In the words of Gucci Mane, "A man can get lost in the sauce, but the same man can be lost without the sauce."

It's natural that here on hacker news we spend most of our time discussing protocols and implementation details. No, protocols alone are not a solution but they are important. What's the point of just re-inventing centralized social networks over and over again? That being said, in order for any of these protocols to reach the masses the protocol itself needs to be invisible to casual users. If the marketing for your new social network is "It runs on this cool decentralized protocol!" you will never reach a non-technical audience.

The end product needs to be as good and as easy to use as centralized equivalents even if that means making some compromises.

The point is to iterate, innovate, and compete. Name one major social media site today that was based on a “new protocol”? Answer: None. They all started as slight twists to an existing site. It’s kind of strange to me that the word “central” has such a bad rap when it really just describes an efficient means of organization, which naturally lends to other efficiencies.

> Name one major social media site today that was based on a “new protocol”? Answer: None.

If one already existed then this title of this post would be 'ActivityPub is the Now' instead of 'ActivityPub Could Be the Future'. Efficiency isn't the only metric and comes at the cost of freedom and resiliency.

“Efficient” perhaps, but also typically controlled by a single entity that often ends up using its power in ways that don’t benefit its users. It’s not really about the technology, it’s about the power dynamic that technology leads to.

Webmention and Microformats2 are the present and the future. They extend blogs with social features. Your blog is your profile. The blogs you follow are your feed. You can send and receive replies, likes, etc. from your own blog with Webmention. Blogs are already a decentralized social network. Webmention and Microformats2 extend what we already have.

Check out https://IndieWeb.org to learn more.

While I can see the appeal, this seems rather blogger centric. And the problem with basing a standard of interaction on that is the 1% rule: 90% of people only read, 9% interact with content and the remaining 1% actually produces new content.

Practically it seems more likely that the final method will be decided upon by the 99% of people following blogs, not the 1% making them.

> I have noticed a tendency for people supporting older, similar protocols to wonder why ActivityPub got so popular while their own stagnated

How do ya'll feel about ActivityPub on a technical level? I read the ActivityPub, ActivityStreams, and JSON-LD specs a couple years back, and came away feeling like it was a bit much. Wouldn't JSON RSS with some sort of web push notifications get us 80% of the way there? Are there simpler alternatives already in the wild? Or am I missing something?

My impression, and I've only skimmed through things at the technical level, is that ActivityPub isn't far from where RSS and various web push notifications might have naturally converged if things hadn't jumped tracks to walled gardens for several years in the middle there.

Some of that feeling is because my introduction to RDF was itself buried in dealing with the real world complexity of 90s and early 2000s RSS feeds. JSON-LD is no worse than early RDF, and in some ways better, clearer, easier to understand. Especially it feels easier to understand why it is useful to the ActivityPub standard, versus as complicated as RDF was it was sometimes hard to understand the impetus to bolting it on top of RSS, if for no other reason than that ActivityPub was built more directly around JSON-LD as opposed to RDF really was bolted on into the middle of the RSS soup (and its dozens of mostly compatible versions) and it was very confusing what/where/how RDF applied anywhere to RSS.

Some of the other parts of ActivityPub similarly seem smarter, simply better versions of now lapsed and/or only half-forgotten "standards" like PingBack/TalkBack or even the original goals of the (real) original OpenID efforts.

JSON Feed, the most widely accepted RSS in JSON standard, has so far managed to intentionally avoid depending on JSON-LD so far, but it's also tried to intentionally be a minimalist subset of RSS and all of the RDF in RSS stuff has been out of scope. Presumably should any of that be relevant again, JSON-LD would be the natural successor. (Similar too, that JSON Feed so far has left notifications support out of scope, but if it did expect to move in that direction they would be remiss to entirely avoid looking at what ActivityPub has already standardized.)

Thanks for the breakdown

JSON-LD is not specific to ActivityStreams/Pub, it's a general mechanism for expressing any kind of RDF/Linked Data as reasonably idiomatic JSON. It makes sense for a federation-focused spec to use it so that it can be extended seamlessly with other sources of Linked Data. Social Linked Data (SOLID) will most likely rely on these mechanisms to interoperate cleanly with ActivityPub/ActivityStreams, for example.

Yes, I mentioned it because it's a (soft?) dependency of ActivityPub

In support of ActivityPub, what are some good intro/tutorial resources?

Any recommendation for a cloud provider to host a Mastdon server? DigitalOcean vs. AWS?

The admin of tech.lgbt is working on a collection of resources. You might find something useful in this thread: https://tech.lgbt/@david/103986050103236381

Darius Kazemi's https://runyourown.social/ is a useful resource, especially toward some of the more non-technical (and thus social) aspects.

I wouldn't go with AWS or anything that advanced for just running a Mastodon server.

I personally like Vultr for VPS's, DigitalOcean is okay too.

If you want managed Mastodon hosting, I can vouch for https://masto.host/ - it's really good, have rarely had issues, and if ever I did, the support is amazing.

Unless you're trying to get AWS experience with a side project you'll actually use, in which case it's worth looking into -- people have gone whole hog and set things up to use a managed DB and everything.

There was a link on HN yesterday about how Emacs was a great success for 'malleable software' because despite being less flexible than some other programmable systems, it came with a built-in application that was usable out-of-the-box (i.e., a text editor).

HTTP won big because it had the web -- Mosaic and Netscape. Spreadsheets won big after VisiCalc showed the way.

Where's the app for ActivityPub? I'm not sure I've ever seen "killer protocol, then killer app". It's always "killer app, then extract killer protocol". You need a carrot.

Mastodon, FWIW

If the network of decentralized social websites grows large enough, then it can overtake Twitter and even Facebook. Just as the World Wide Web won over AOL in the early days.

The network effect is powerful.

The problem is and always will be the friction associated with discovery. If I want to add my friends, colleagues or family on Facebook they have most likely already been suggested to me. One click. I didn't even have to ask for their handle.

How can we create a more powerful network effect through a decentralised network without some centralised directory?

I posted some thoughts on this in my Show HN thread https://news.ycombinator.com/item?id=22844481

I'll quote it here

> My long term thoughts on aggregators for fediverses:

I think aggregation/curation sites (like pixelfed.club) can be a decentralized complement to the fediverse. The fediverse generates the content. Aggregators, can curate the content for specific topics and help new users discover content. Anyone can start a fediverse instance, and anyone can start a aggregation/curation instance.

What product features does Mastadon offer over twitter/facebook? Because unless it's something useful/significant, 99.9999% of twitters/facebook users do not care about it.

Mastodon can appeal to people who enjoy the idea of twitter but want to be able to have their own cordoned off community version of it with the ability to whitelist other communities that are allowed to interop.

that’s great for those users, but forget about mass adoption

Can one easily hook up ActivityPub to WordPress, etc?

I've wanted a Twitter/Facebook/Instagram replacement platform with syndication to ActivityPub.

It's not perfect but this plugin is an incomplete implementation: https://wordpress.org/plugins/activitypub/

It will not work because there is no way for anyone to profit from it. That's the sad but inescapable reality of the internet today.

The only way grassroot movements can succeed is through engaging in mass collaborative corruption. Thankfully, cryptocurrencies have proven the effectiveness of this concept. You just need to invent a financial instrument which has no value initially but which can grow in value as it becomes more popular - This gives your financial instrument 'potential value' - This potential value allows your financial instrument to be used to 'bribe' journalists to hype up your product and convert its 'potential value' into 'actualized value'.

It is a bit like a pyramid scheme, but everything these days is a pyramid scheme. The only way to compete within the gigantic pyramid scheme that is our financial system is through other even more elaborate pyramid schemes.

More concretely, the reason this is necessary is because corporations are constantly 'bribing' journalists by holding ad revenue over their heads and restricting the kinds of things that they are allowed to write about; so it's essential for grassroot projects to have a mechanism in place which can counteract such market forces which intentionally limit the visibility of new 'unproven' products.

There's some truth in this, but you extrapolate too far. 1) UX is a bigger problem than the lack of financial incentives in the system though the two are related somewhat 2) There are audiences in these ecosystems, and I think monetization will find it's way in appropriately somehow. It's not impossible, by my estimation.

Serious question: in what way does AP provide more privacy than Facebook?

It’s obviously not focused on private comms, so it won’t be a replacement for actual e2e private messaging and chat.

For the public content, the lack of commercial advertising incentives is probably a big one. IME the client apps and server instances aren’t injecting trackers and selling ads based on user behaviors.

If an instance or client went rogue and started introducing such practices, it would likely be moderated out of relevance.

There's nothing stopping an implementation from encrypting and locking things down, but so far every popular AP platform is focused on public content.

Ok. But note that "locking things down" might be not that simple, as you'd need good privacy controls. We all know that Facebook's privacy controls are/were lacking in many respects.

I am not even sure ActivityPub is the past, let alone the future. I agree with the philosophy behind it, but people are always going to be more willing to go it alone on this type of thing.

Been hearing this for a while. The future sure comes slow?

It's a great protocol and system but not a great product/brand.

ActivityPub is as decentralized as email and RSS feeds.

Unfortunately nothing in such protocols prevents the gmail problem.

If ActivityPub gains adoption, it will end up like email, where there are a few large central providers that 99% of the users use.

A crypto based protocol will be the only way to achieve true censorship resistance and decentralization.

It seems relevant that it's decently easy with Mastodon 3.0 to move from one server to another, and the UX Just Works. Hard to imagine gmail doing the same. If I'm mad at Google there are a lot of factors stopping me from migrating my email because they own my identity.

Reply on news.ycombinator.com