ActivityPub support #1557
Comments
|
Can you compile a checklist of things that need to be implemented to become AP-compliant from a server-to-server perspective? (Not interested in client-to-server at all, right now) Something like inbox, outbox, representation of stuff, etc. My biggest desire wrt. AP is the ability to implement follower-only messages as well as direct messages without leaking them to old GNU social server that don't understand privacy scopes. As far as I understand AP servers must respect the addressee collections, so it should be a thing out of the box, plus there are no old faulty AP servers to worry about leaking stuff to accidentally. |
|
cc @evanminto |
|
I'm already gearing up to look at what still needs to be done for implementing AP integration Friday through this weekend. I've been within the W3C group, so I have a good understanding of it already. Working off of the existing AP mastodon branch, of course. Anybody else want to look at it with me? FTR that's also my biggest desire wrt what AP integration would provide. |
|
@Gargron sure, I drew up a list for pump.io. pump-io/pump.io#1241 is our tracking issue but I have a generic version of that list that I'll find for you shortly |
|
I am suspecting that the first step is writing JSON representations of ActivityStreams items. Currently we do that for Atom XML only. The logic should be similar enough, except you'd probably write Rabl templates instead of using a class like AtomSerializer and Ox (although from a performance perspective, doing something with Oj directly without invoking Rabl would be a huge boost) |
|
@Gargron yeah I'm not familiar with exactly how the OStatus protocol works but probably for any endpoint that would previously return some ActivityStreams XML you'll want to just content-negotiate and return JSON when needed. Note that ActivityStreams 2.0 also includes an appendix on how to "upgrade" ActivityStreams 1.0 objects to AS2, so you could probably just do that in the request handler and serve the result |
|
I didn't get very far in my AP integration before I got sidetracked by some personal life stuff, but there IS at least a basic example of what Gargron is talking about for representing accounts as Activity Streams 2.0 on master. I have some more unfinished work (rudimentary outboxes) on a private branch. I was planning on jumping back into it a bit this weekend too, and I'm glad to have some more folks looking into it! |
|
The ActivityPub network page on the w3c wiki has some info on the progress happening in other social networking software projects. |
|
That sounds like a reasonable first step: the ActivityStreams 2 data/vocab model. Get existing endpoints to render content-negotiated JSON (application/activity+json) for posts/feeds. I still need to look to see what the existing work does, but let's get a checklist... with this on top. We should obviously validate against pump.io's AP implementation and any others that might be at all ahead: https://www.w3.org/wiki/Socialwg/ActivityPub_network (rstatus is on there... should I even? nono) and Soci-el and Pubstrate which are both a kind of reference implementation. |
|
@Gargron added a checklist to the issue description |
|
@wilkie note also the pump.io's implementation is in very early stages and is very much a WIP. That being said it's very high priority for us and I'm hoping to at least make good progress by the end of the month |
|
@strugee definitely understandable. hopefully we can work off of one another in terms of testing implementations. pump.io is obviously much more of a real-world federation than the reference libraries. |
|
@wilkie definitely. I should note also that our implementation may be slightly wonky since we have a large existing network to worry about... but Mastodon has the same problem, and in an even worse form (since at least pump's existing stuff is pretty close to AP) |
|
How does discovery work? Links to AP resources from Webfinger? |
|
Authentication/authorization for server-to-server communication - is there anything prescribed for this? Do we just reuse the magic key signing concept from Salmon? |
What do you mean by "discovery"? Discovery of what?
No formal prescription, but there are some suggestions for auth schemes that we expect people will probably want to focus on. Eventually these may become standardized as extensions to ActivityPub core. https://www.w3.org/TR/activitypub/#authorization |
ActivityPub does "follow your nose" of links to links to links; a person's identifier is a uri of some type, as opposed to using a "magic" type toplevel tied-to-domain route such as |
Okay, this sounds like the Salmon verification mechanism. We already have public/private keys generated for accounts. Could sign and verify messages this way, though perhaps a HTTP header signature as used in PubSubHubbub would be more applicable than the magic envelope Base64/XML approach of Salmon.
The less things we have to change to get AP in, the better. We do user discovery based on WebFinger. So now we just need to assign more links to AP-specific resources in the response. I am guessing there are only two such links, inbox and outbox, am I correct? |
Those are the big ones, but you probably also want to add the read-only collections of followers / following (and maybe also likes, if you like); see the Actors section of ActivityPub. (PS: The way you'd do Webfinger discovery via ActivityPub btw is to do the "acct:foo@example.org" to look up the http(s) url, then do content negotiation to pull out the ActivityStreams actor profile object... which is just some json. You could also just start passing around peoples' handle uris as their main identifiers, but I know that would be a bigger change.) |
ghost
mentioned this issue
|
Sorry, I'm a little confused about the WebFinger discussion. Wouldn't relying on WF for account discovery make Mastodon incompatible with other AP implementations? I figured we'd be building new AP-specific endpoints, in which case we would just use URLs to JSON resources as @cwebber mentioned. I'm not super familiar with WF and how it's used on Mastodon, so I may just be missing something. |
|
Indeed, it would seem unnecessary to go through the process of implementing a new protocol without having compatibility to other AP implementations. Using webfinger would essentially kill that. Relating to signing, it would be great if the first implementers could somehow agree on a way, otherwise there is risk that many implementations will be incompatible due to different signing required. It would be great if we could agree on Linked Data Signatures embedded into the payload, like the examples in https://w3c-dvcg.github.io/ld-signatures/#linked-data-signature-overview . Using HTTP signatures would IMHO not be a good idea, since often signatures need to be checked at a later point. The receiver might delay the signature check (due to processing load or otherwise). Also having the signature in the message itself allows it to be relayed, if needed, which AFAICT is not possible with HTTP signatures. For example, the relay system used with the Diaspora protocol relies on the possibility to forward payloads using a third-party server. Would love to build AP support for that once my federation library has AP support :) @cwebber what do you think, is there any possibility to still clarify the signature part in AP spec to recommend Linked Data Signatures over anything else? Right now it is kind of confusing, saying "Linked Data Signatures and/or HTTP signatures", which basically might mean some implementers implement one, one or the other or both. |
|
@jaywink agreed it's kind of messy having the spec not pick a method. See w3c/activitypub#77. Probably the way forward is to closely track what folks are implementating, in a very visible way, and see if we can get quick convergence. If we can, we can at least observe that, even if the spec doesn't pick one. For more on this, we should probably move to an AP issue; feel free to create one. |
|
I'll also add different auth profiles to the extensions page. This seems like a great thing to pursue in the Community Group. |
|
Here's a question, how hard would it be to use plain http(s) URIs as the identifiers on the federation protocol level? webfinger identifiers could still be used to look someone up in the UI |
|
By the way, if ActivityPub is a lot to absorb still, I've written a tutorial that might be a good way to grasp the concepts quickly! |
|
@cwebber Is there a typo in the very last example? It sends the message to "alice/following", rather than "alice/followers" Also, discovery of the actors' URLs is still a mystery to me. The reason I brought up Webfinger before is simple: I am Gargron@mastodon.social, you are cwebber@toot.cat. I know how to address you in a post by typing @cwebber@toot.cat, my server knows that this means it needs to ask toot.cat for the user cwebber. This is discovery based on handles. I don't understand how this is supposed to happen for AP actors. |
|
I think we can close this? 😀 1.6.0 implements ActivityPub |
|
Awesome. 😁. We've just mentioned it on the w3.org homepage news, too. Related awkward question: did you pay attention to the client-to-server part of the spec? I understand you've got a good working protocol there and no substantive reason to change. Do you think we should take out that part of AP and switch to documenting what Mastodon does, so the industry can converge better? |
No no, I don't expect you to do anything like that. Mastodon REST API is very Mastodon-specific, and that's also part of my reasoning for not really wanting a standard client-to-server API... With our REST API app developers have a very clear-cut direction for designing their app, and any Mastodon app acts more or less the same. But would a Mastodon-type mobile be a good fit for MediaGoblin, or vice versa? I don't think so. C2S basically means the server has to do little more than perform distribution and some persistent storage. The business logic, anything that makes Mastodon different from say, Hubzilla, moves to the client. |
|
Can you give me an example of that "business logic"? What do you expect to be distinctive about Mastodon for years to come? .... And why/how is that distinctiveness helpful to end users? I've always imagined these systems should all be the same, so users can move between them and connect between them. Curious what's missing from my mental picture. The 500char limit comes to mind, but that seems pretty trivial... |
|
@sandhawke Right now: When you use Mastodon, you have an expectation of capabilities it has, UX, packaging, branding. App developers just have to implement the REST API, and there's a whole bunch of apps for iOS, Android, Windows Phone, etc - all relatively simple to make. Now, if instead it was up for the app developer to come up with "this works like twitter" or "this works like instagram" or "this works like facebook", you would have Mastodon for Android, and nothing else, because that functionality would be entirely within one app on one platform, that app would be as hard to make as Mastodon right now, and for other platforms you might not have a port of the thing, you might have totally different apps instead. |
|
I agree the current Mastodon brand wouldn't make a whole lot of sense in the world I'm imagining. Is that important to you? Would it be okay if people starting thinking they were using (android UI) Tusky, and talking about Tusky, and not even know or care their server was running your code? If Tusky had account creation that'd be pretty easy. Or if someone made another server speaking the Mastodon client-server API, and called it tusky-server, and it got really popular, mostly just used with Tusky? What harm would that do? And then what if they upped the character limit...? Also, aside from the UI, what's the difference between Twitter and Instagram? I'm not a heavy ig user. Mostly they seem to have the same functionality. Ponder, ponder. Oh, yeah, you can't post text to IG, only pictures and video. And that means you can't post links. And you can't share/boost. And replies are not first-class objects. It's funny how two systems can feel so similar when one is so restricted. So, are we doomed to a future where I'm going to always have to use eight different platforms, each with its own quirks and privacy issues and abuse issues, if I want to stay in touch online with 90% of my friends and family? (To reach 99% of them I'd probably need to be using fifty platforms, including the postal service and voice telephone calls!) |
|
@sandhawke I don't think gargron is primarily talking about the brand. The mastodon server is not a fully-general ActivityPub server, it's built with a specific set of assumptions and limitations. We don't believe these assumptions are going to be the same with everyone we federate with—that's the whole point of federation. But every client that wants to interact with our server does need to be aware of these assumptions and intentional limitations. Otherwise it would just be a very limited and confusing user experience. I think there are ways to address both of these problems, and I think personally I would be interested in seeing mastodon speak some of the C2S api, but the problem is that it addresses a different use-case and has a fundamentally different scope then mastodon's current API.
Isn't this why we have S2S federation? So you can talk between different platforms? |
|
@nightpool From how you frame it, it sounds like it'd be very useful to spell out a Mastodon profile for AP. Explicitly and precisely state every restriction Mastodon makes from full AP, so people know what they are trying to interoperate with. Probably also distinguish which restrictions are expected to remain in place forever and which are subject to change at any point. Doesn't S2S federation suffer from all these interop problems, just like C2S? I mean, how could you federate from Twitter to IG, given just the differences I named? Or if I started a Mastodon instance which I modified to increase or decrease restrictions, how would that impact users of my system and others' systems? |
|
@Gargron and I have already talked about this plenty over PM, and I know he's unconvinced of AP C2S... and that's fine! It's a lot less important than S2S. I still think it's likely doable and desirable (would be nice to use my AP emacs client with Masto) but I'm not a Mastodon dev, so :) Note that one (slightly futuristic?) clear use case for using the AP C2S API (aside from giving a nice universal C2S API that you could use for multiple applications) would be if you would want to support end to end encryption as an optional feature, In that case the communicating clients could wrap up the AS2 objects in an encrypted envelope and send them to each other across the servers, without the servers being able to read them. Since the object you unpack is also AS2, assuming your client already knows how to render AS2 because you're using the C2S API rendering it should be quite feasible. (Of course there's a whole swath of other challenges around key management in E2E!) |
Technically I don't have much against a world like this, but this would make educating the masses even harder in my opinion. Instead of talking about "switch to Mastodon", we'd have all this potentially half-finished apps trying to get people's attention, and among the noise the fact that they're all actually using ActivityPub in the background might not get noticed and some apps could slip by that don't use it at all. I'd also like to note there is no precedent for anything like that. While both XMPP and IMAP/POP3/SMTP have defined client-to-server APIs, their functionality is so narrowly focused that there is significant difference between using one e-mail app over another. ActivityPub allows you to do a lot of things through its vocabulary.
No, or maybe to some extent, but we can solve these problems at the server level. Much better than having app developers have to individually solve it in each app. |
|
How do you handle federating to a server that's images-only? Or has a 140char limit? Or which doesn't do first-class replies? Or boosts? My impression has been, instead, that we need to converge on a complete and precise model, and let systems compete on UI and policies and performance and price. I think a world where the model is different in different parts of the federation is never going to go mainstream. But... hopefully I'll be proven wrong. |
This reminds me - @Gargron how does Mastodon handle or plan to handle if an incoming In general, to the thread: Interesting reading, but tbh, I don't think there will be a "one use case fits all". And actually IMHO that would be the worst thing that could happen. We have fantastic apps and platforms because people want different things. Some people want short video clips, some auto-destructing messages, some only text, some hashtags, etc. People have different needs and choose platforms according to their needs. I agree totally that S2S is the only way to bridge, partially, these platforms which have different features.
Exactly, this as well. I can't see any platforms going to support everything it can represent. |
|
@jaywink "how does Mastodon handle or plan to handle if an incoming Note(?) has over 500 characters" this isn't a new problem. I've seen a few solutions. the one I've implemented back in the day was you would truncate them as you receive them and link to the originating server with a "..." or "read more" or whatever link in your rendered version. |
|
@wilkie yes though this was a very specific question regarding Mastodon :) I had a quick look in the code but couldn't find any place - but my RoR isn't that good. |
|
I'd like to share a thought on this that I've been thinking since before I started work on an ActivityPub side project (and I hope that it's not too off-topic). And that is "a protocol is not an application". It seems to me that historically there has been a tendency for open social developers to think a lot about protocols and not much about applications, assuming that the protocol is, in some sense, the application. The ActivityPub spec provides the primitives for a lot of different types of applications; a Facebook-like app is not a Twitter-like app is not an Instagram-like app, but you can express any of them with ActivityStreams objects. And a common c2s API is a convenience for anyone implementing a client -- but it does not make much sense for there to be a generic ActivityPub client app. |
|
Yeah, same here. |
|
jfmcbrayer: you should share your opinions on the ActivityPub or socialcg
github page: https://github.com/w3c/activitypub
…On Thu, Sep 21, 2017 at 9:09 AM Eugen Rochko ***@***.***> wrote:
Yeah, same here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1557 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORV9s1pC1PzCvfp9r5j0tXkDW7WHmSks5skmAOgaJpZM4M6Y2s>
.
|
|
@nightpool I really doubt that they would remove c2s from the standard from this feedback, so that's quite pointless. Mastodon, on the other hand, does not implement c2s and I see no reason to spend time on that right now. |
|
I was just saying that if he wants to have a conversation about it, they'll
be happy to do so.
…On Thu, Sep 21, 2017 at 9:18 AM Eugen Rochko ***@***.***> wrote:
@nightpool <https://github.com/nightpool> I really doubt that they would
remove c2s from the standard from this feedback, so that's quite pointless.
Mastodon, on the other hand, does not implement c2s and I see no reason to
spend time on that right now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1557 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAORVzIDkNJktUBYxtTH3DCT7GVylNQYks5skmIHgaJpZM4M6Y2s>
.
|
|
I don't think c2s should be removed from the standard; I think it's a great convenience for client app developers, especially as client libraries mature. I just think an ActivityPub client that is not designed around the "business logic" of a particular ActivityPub application would not actually be useful for anything but testing. |
|
@sandhawke Re: "And then what if they upped the character limit...?" Mastodon.host is an example of an instance whose limit is 1024 characters per toot. When I post from there with my https://mastodon.host/@FuzboleroXV account, all (?) other Mastodon instances that are using the default 500 limit are still showing the full posts (all 1024 characters). They just do not allow their own users to write that long toots. Within the Mastodon realm, this works well, and there is no real "issue" with a "fixed" character limit. It is not and does not need to be an enforced standard. Whenever such longer posts are sent to other (non-Mastodon) systems, they already need to cope with the the fact that they will continue to have to handle different lenghts from different sources/systems (which for example can be done like @wilkie is describing with the "read more" example). |
…upstream Merge upstream changes
ActivityPub is a standards-track protocol for server-to-server federation, as well as client-to-server APIs at the W3C. https://www.w3.org/TR/activitypub/
My understanding is that this is something Mastodon is somewhat interested in already, but I'm filing an issue to have "somewhere" to track this.
Edit: here's a checklist for things to implement. I cut out client-to-server stuff, although most of it applies to both.
Does your application implement URLs for:
idproperties? (Section 3.2 Retrieving objects)Does your application handle:
Do you:
The text was updated successfully, but these errors were encountered: