[HN Gopher] Introduction to ActivityPub (2021)
___________________________________________________________________
Introduction to ActivityPub (2021)
Author : srameshc
Score : 136 points
Date : 2023-07-09 11:56 UTC (11 hours ago)
(HTM) web link (socialhub.activitypub.rocks)
(TXT) w3m dump (socialhub.activitypub.rocks)
| mezobeli wrote:
| Try Nostr
| miki123211 wrote:
| AP is a really terrible protocol, but it'll probably dominate
| this space in the long-term because of the "worse is better"
| effect.
|
| The AP specification is a joke. It's a typical W3C mess of
| documents referencing documents referencing documents that
| reference yet other documents, and you have no idea which of
| those you have to read, and in what order. For example,
| ActivityPub requires you to understand ActivityStreams and often
| mentions JSON LD, but you don't really need to understand much
| about JSON LD to understand the AP spec. Even worse still, some
| parts of the spec sound just as authoritative as everything else
| while being completely useless. For example, the client-to-server
| part isn't actually implemented by any of the major
| implementations, and if what you want to do is write a Mastodon-
| compatible client, you need to look at a completely different,
| unspecified API, which the major implementations implement in
| similar but slightly different ways, often violating the
| assumptions that some clients made. Yet other parts of the
| protocol are underspecified; to understand how signatures are
| handled, for example, you basically need to read the source code
| of one of the implementations. Things are so bad that people had
| to write ActivityPub specification reading guides[1].
|
| Leaving the specification aside, the protocol as implemented has
| a bunch of other issues. If you want to make your website
| ActivityPub enabled, to publish news like you would on an RSS
| feed for example, you can't just chuck a JSON file on a CDN and
| call it a day, you actually need to keep track of a list of
| subscribers and proactively push out updates to interested
| servers, which is complicated from an infrastructure standpoint,
| has GDPR implications, doesn't play well with existing CDN /
| caching infrastructure and headless CMS solutions, and is an
| overall pain in the ass to implement. The protocol still doesn't
| have a satisfactory migration solution, migrating between
| Mastodon instances is a difficult process with lots of steps, and
| you can only migrate (most of) your followers, but not your post
| history. If your instance shuts down for any reason or your admin
| decides to ban you, you lose everything and you can't migrate any
| more. Your instance admins can decide not only what content
| you're allowed to post, but also what content from other
| instances you're allowed to see. Most admins abuse that power
| liberally, making it impossible to follow people from any
| instance that isn't leftist enough, and those that don't are
| often shunned, cut out themselves or forced into submission. The
| community is very cult-like, has a "you're either completely with
| us or against us" mentality, and if you're against us, we will do
| everything in our power to shun you and make your content
| invisible to the rest of the fediverse.
|
| If your admin decides to suspend an instance, your
| follower/following relationships with that instance are gone
| forever. Neither migrating away nor your admin deciding to un-
| suspend the instance will fix that. If you could find a
| vulnerability that allowed you to control a majority of fediverse
| instances, and such a vulnerability existed[2], you could
| basically destroy the network with a bunch of well-placed
| defederation requests, and no restoring from backups would ever
| fix that.
| mdaniel wrote:
| I think you some references, although I'm pretty sure I know
| what [2] is
| matricaria wrote:
| I think it's sad that Discourse is not federated as it broadly
| used in open source software. Maybe this will be added in the
| future?
|
| Or maybe the forums will move to Lemmy as it matures.
| mariusor wrote:
| They did add support a short while back:
| https://github.com/discourse/discourse-activity-pub.
| [deleted]
| idlewords wrote:
| [flagged]
| nologic01 wrote:
| This reads more like a collection of links and resources rather
| than an introduction.
|
| There should two proper introductions, one non-technical (but not
| patronising one) that would explain in clear terms and maybe a
| few diagrams and mockups what type of experience is supported.
| Also a more technical one that clarifies among others what is
| exactly the status quo of the various implementations of the
| protocol.
|
| Being decentralized and a collection of disparate, opinionated
| and shoestring budget efforts means that there is a penalty in
| terms of good exposition and documentation.
|
| For better or worse the grace period is over for the fediverse.
| The stakes have been raised.
| konart wrote:
| >one that clarifies among others what is exactly the status quo
|
| Everyone do whatever they want to and try to support Mastodon
| custom `toot:` namespace which cannot be resolved and has to be
| hardcoded.
| progval wrote:
| Does it? Mastodon writes "toot":"http://joinmastodon.org/ns#"
| in its objects' "@context" as required by JSON-LD. What's
| wrong with it?
| mariusor wrote:
| The fact that it resolves to a 404 page?
| konart wrote:
| The thing is you should be able to send a request and get
| back the content of this context for dereferencing like so:
| curl -X GET -H "Accept:application/ld+json"
| https://www.w3.org/ns/activitystreams
|
| Mastodon does not provide this data, so this is a fake
| namespase
|
| https://github.com/mastodon/joinmastodon/issues/148#issueco
| m...
|
| https://github.com/go-fed/activity/issues/152
| progval wrote:
| You (and the people in those issues including Gargron)
| are confusing contexts URLs and namespaces.
| "@context":[{"toot":"http://joinmastodon.org/ns#"}]
| defines a "toot" prefix for the
| http://joinmastodon.org/ns# namespace and namespaces
| don't have to resolve to anything.
| "@context":["http://joinmastodon.org/ns#"] would be
| incorrect, but that's not what Mastodon does.
|
| Some of the namespaces used by the JSON-LD spec itself
| (https://www.w3.org/TR/json-ld11/#conformance) don't
| resolve either. For example: $ curl -X
| GET -H "Accept:application/ld+json"
| https://www.w3.org/ns/prov -L <!DOCTYPE HTML
| PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head>
| <title>406 Not Acceptable</title>
|
| EDIT: it seems the source of the misunderstanding in the
| issue you linked is that GoToSocial used to send
| "@context": ["http://joinmastodon.org/ns", ...], ie.
| using it as a context URL instead of a namespace: https:/
| /github.com/friendica/friendica/issues/10740#issuecom...
| konart wrote:
| Okay, I stand corrected.
|
| Examples at
| https://docs.joinmastodon.org/spec/activitypub/#featured
| and this new information give better understanding of the
| spec. (I find it quite confusing anyway to be honest).
| progval wrote:
| Yes, I agree. I work with JSON-LD in various contexts,
| and while it's lovely in theory when only working with
| people specialized in knowledge graphs, in practice it's
| full of counter-intuitive stuff like this. I believe that
| RDF/XML as capable and less confusing, but it is scary to
| programmers because XML.
| Ciantic wrote:
| I presume this is here partly because Threads is in the news. To
| me interesting part will be what subset Threads will support?
|
| For instance, ActivityPub specs start like this:
|
| "It provides a client-to-server API for creating, updating and
| deleting content, as well as a federated server-to-server API for
| delivering notifications and content."
|
| However, that client-to-server API is not even implemented by
| Mastodon. It's unlikely Threads will support it either, leaving
| those who want to make own clients in the cold.
|
| Then there is stuff like outbox, which contains past messages,
| but for instance, Mastodon does not fetch old messages at all,
| causing a subpar experience: "Older posts from other servers are
| not displayed" when browsing profiles.
|
| If Threads don't see the need to support outbox either, it makes
| browsing Threads content from your own small server an
| infuriating experience.
| shagie wrote:
| https://www.w3.org/TR/activitystreams-vocabulary/#extendedty...
|
| > Support for specific extended vocabulary types is expected to
| vary, with implementations only selecting the extended types
| and properties that make sense within the specific context and
| requirements of those applications. However, to avoid possible
| interoperability issues, implementations must avoid using
| extension types or properties that unduly overlap with or
| duplicate the extended vocabulary defined here.
| unshavedyak wrote:
| Is that client-server API robust enough to .. care? Why don't
| other (any other?) FOSS implementations support it?
|
| I'm toying around with my own and that's interesting. I'd love
| to support it but if no one else supports it no clients will
| support it either. Granted eventually i expect i'd want some
| client-server API so i may as well use ActivityPubs.
| Nonetheless the lack of adoption feels odd.
| mariusor wrote:
| There are other projects that support the client to server
| part of the specification (see my profile for an example in
| the FedBOX project, and from the more mainstream ones there's
| Pleroma AFAIR). Generally developers justify not adding it to
| their implementations with the fact that is not specified in
| sufficient detail. Personally I think it's mostly laziness
| and a lack of imagination - but I'm biased.
| tedunangst wrote:
| The client server protocol lacks support for many basic
| operations, like search. It's a late addition to the spec,
| because somebody felt a server protocol shouldn't be released
| without a client protocol. Swap the polarity of the inbox and
| outbox, and presto you've got a client protocol. Except clients
| don't want to talk to servers the same way servers talk to
| other servers.
| anileated wrote:
| It seems logical if Threads focused on client-to-server
| interoperation first, since in theory that would allow more
| people to use third-party clients but not third-party servers
| so Meta gets a hold of all the unencrypted messages.
| thejohnconway wrote:
| I'm pretty sure they are going to do the opposite, support
| server-to-server, and never support client-to-server. They
| have been meeting with the maintainers of Mastodon and admins
| of large instances. Their stated goal is to allow migration
| off without losing your social graph (this is obviously a lie
| about motivation, but that's not what I'm taking about here).
| This is all about server-to-server implementation.
|
| So, they are going to be part of the server-to-server
| Fediverse, and keep all of the juicy app data from Threads
| users to themselves.
| Lt_Riza_Hawkeye wrote:
| Yes, plus if they support client-server then kill it later,
| they risk the same kind of backlash that happened to
| Twitter and Reddit when they killed third party clients.
| But if they only support server-server when they kill it,
| they can just send an email to all the geeks telling them
| "import your account into threads by X date!" and most
| "normal" users will never notice
| thejohnconway wrote:
| Supporting server-to-server ActivityPub is _slightly_
| risky for them as it gives people an alternative, and
| there will always be outward bleed. On the other hand I
| think it takes a lot of pressure off potential legal
| troubles around being a monopoly (which they must be
| worried about if they actually manage to kill Twitter).
|
| I predict if they manage to be the overwhelmingly
| dominant platform in the Fediverse, they'll keep it
| working. If they see another big competitor jumping in
| and taking a lot of users (or hell, if Mastodon starts to
| eat their lunch), I'm not so sure.
| RobotToaster wrote:
| >Then there is stuff like outbox, which contains past messages,
| but for instance, Mastodon does not fetch old messages at all
|
| It's infuriating how little support activitypub outboxes have.
| It seems like the perfect way to make small instances work
| well.
| mariusor wrote:
| I think the justification Eugen (Mastodon's main developer)
| gave for not loading a user's past activities is that it
| would actually harm smaller instances when a user goes viral
| and the whole network hammers their servers for their
| content.
|
| I am not convinced of the reasoning, and, in my opinion it's
| actually working against the idea of "federation", and even
| against the whole paradigm the internet is built upon: as a
| UserAgent you should retrieve content when the user requests
| it.
| jameson71 wrote:
| I don't understand why other instances wouldn't cache the
| older content and periodically look for updates
| worrycue wrote:
| > I think the justification Eugen (Mastodon's main
| developer) gave for not loading a user's past activities is
| that it would actually harm smaller instances when a user
| goes viral and the whole network hammers their servers for
| their content.
|
| Maybe we need some kind of protocol that can spread the
| load where popular messages are duplicated across the
| network instead of being stuck on one node that can get
| overwhelmed.
| ComodoHacker wrote:
| Maybe we don't need to value virality so much.
| mariusor wrote:
| I doubt "valuing virality" is the real problem. But when
| you're exposed to a universal network whose numbers
| increase every day, there are moments when it happens no
| matter if you want it or not. The "slashdot effect" has
| been coined maybe 25 years ago, so it's obviously not a
| new thing. :P
| charcircuit wrote:
| Virality will happen regardless of your intentions. Your
| systems need to be designed to handle it.
| still_grokking wrote:
| > Maybe we need some kind of protocol that can spread the
| load where popular messages are duplicated across the
| network instead of being stuck on one node that can get
| overwhelmed.
|
| You mean like any proper P2P protocol?
|
| Add to this multi-cast on internet level, and everybody
| could actually operate something like YouTube on their
| internet router...
|
| But of course economic interests of some (already ultra
| rich) minority will prevent that forever, even we could
| have it just right now form the technical standpoint.
| mariusor wrote:
| Since ActivityPub is mostly composed (75%) of immutable
| json payloads, they are very suitable for caching. The
| existing infrastructure should be more than enough.
| konart wrote:
| BitTorrent?
| JamesLeonis wrote:
| Not the hero we deserved but the hero we needed.
|
| The irony and tragedy of the Internet is BitTorrent
| solved Internet Scale at the protocol level, but is at
| odds with how content companies, ISPs, and Silicon Valley
| want to organize themselves.
| mariusor wrote:
| It's also at odds with how people consume content.
|
| If you cram every social interaction a network has in a
| massive common distributed store (which is what using a
| bittorrent like protocol would entail) you have every
| node requiring to consume gigabytes over gigabytes of
| content, despite being interested in a fraction of a
| fraction of it.
|
| I don't know if nostr or scuttlebutt resolve this issue,
| but if they don't ... how do you imagine a mobile app for
| keeping in touch with your grandma, requiring gigabytes
| of data transfer and storage would work?
|
| At this point people saying bittorrent is a solution for
| social networks are basically just the guys who know
| about hammers and seeing nothing but nails.
| still_grokking wrote:
| Modern smartphones are like the computers end of the
| 90's.
|
| We've run back than Napster and later eDonkey on those
| boxes just fine...
| mariusor wrote:
| Yes, but you were downloading a movie and then you'd
| delete it to make room for something else on your 40GB
| HDD. In this case it would be like you'd try to download
| the whole internet because you're interested in one
| movie.
| malermeister wrote:
| The mobile app isn't a peer in this hypothetical torrent
| network. Your mastodon instance is and it serves you
| using the same client protocol we have right now.
|
| That way, you solve for the potential hosting issues of
| smaller hosts not being able to handle the load in case
| of viral posts etc, all without the clients having to
| know anything about the implementation details.
| mariusor wrote:
| If you still require servers that you need to connect to
| then you kind of lose the benefit of having a social
| network over a p2p protocol. Or you're also thinking that
| the social serving aspect is parallel to the media
| serving aspect that another sibling mentioned.
| JamesLeonis wrote:
| I'm advocating it as the content distribution layer, not
| the social interaction layer. You don't even need all of
| the metadata, as there are BEP extensions to distribute
| that as an index [0] or an RSS-style feed [1]. Images are
| particularly painful, like the previews in Mastodon,
| because they hammer the origin server rather than looking
| around at what other peers have. This problem will only
| get worse as the federation grows in size, both in users
| and in servers.
|
| I say _irony_ because we had all these scaling problems
| two decades ago during the peak P2P years, including
| federation and implicit DDoSing, and BitTorrent emerged
| as the lasting protocol because it could handle the
| scaling issues.
|
| I say _tragedy_ because for this to work you do need some
| openness, which puts people at risk of content companies
| trolling for you, ISPs dropping you, and is completely
| antithetical to the control Silicon Valley demands over
| its users and data.
|
| [0]: http://bittorrent.org/beps/bep_0049.html
|
| [1]: http://bittorrent.org/beps/bep_0039.html
| mariusor wrote:
| Then the fediverse is already there. The video hosting
| service PeerTube uses bittorrent to distribute the video
| among viewers.
|
| There were some plans at one point for another project
| which would deal with music and would host the media on
| IPFS. Sadly I've never seen any progress on it, despite
| the idea sounding very good.
| jameson71 wrote:
| It's not so much Silicon Valley demanding that control as
| Hollywood
| cratermoon wrote:
| NNTP
| tedunangst wrote:
| Some day computers will be fast enough to serve hundreds of
| bytes of json many times per second.
| mariusor wrote:
| They are already if you architect your service for the
| real purpose, which is to store and process ActivityPub
| data. Mastodon however is a CRUD application that has its
| ActivityPub bolted on a totally different data paradigm.
| It takes a lot of computing to make it run fast.
|
| I created an ActivityPub service which (coincidentally)
| uses a similar storage idea as HN - raw files on disk -
| and it runs orders of magnitude faster than a similar
| sized Mastodon server would. Sadly it's not as fast as
| HN, but I'm getting it there. :D
| RobotToaster wrote:
| I think the person you are replying to was being
| sarcastic.
| vxNsr wrote:
| they were, but the point was that mastadon is incredibly
| inefficient and this guy is making a more efficient
| version
| vxNsr wrote:
| I see your profile is full of a lot of the info about
| this, do you have a more detailed write-up expanding on
| how this all works together?
| srameshc wrote:
| I posted this not because of 'Thereads' but because I have been
| trying to implement ActivityPub and somehow I missed this
| document in my previous searches. I want to implement
| ActivityPub support for my blog in some form so like RSS,
| anyone subscribes can listen to it.
| laurex wrote:
| This will be helpful for you https://github.com/dariusk/rss-
| to-activitypub
___________________________________________________________________
(page generated 2023-07-09 23:01 UTC)