New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: implement ActivityPub for federated comments #2337

Open
strypey opened this Issue Jun 2, 2018 · 23 comments

Comments

Projects
None yet
9 participants
@strypey
Copy link

strypey commented Jun 2, 2018

I'm wondering if the DreamWidth crew would be interested in implementing ActivityPub? ActivityPub is a newly published W3C standard for the federated social web. All of the apps inter-operating in the OStatus "fediverse" either have already upgraded to AP (incl. Mastodon and Hubzilla), or will be rolling out implementation in the coming months (incl. GNU Social). AP implementations plans are also afoot among a bunch of federated apps that have been out on their own (eg pump.io), or part of the Diaspora federation (eg Friendica and SocialHome), and there is a bridge to the IndieWeb in development. There are also a bunch of new apps that are being developed with or adding AP support (see: https://gitlab.com/fediverse/fediverse.gitlab.io/issues/8).

The most obvious use case is enabling DreamWidth blogs to be followed by users on microblogging apps like Mastodon, with new posts appearing as a title and a link in user's stream. Comments on posts can appear both in the microblogging app, and made available as comments on that DreamWidth blog (subject to the usual moderation guidelines of that blog). All the network effect benefits of using a comment engine like Quora, Disqus, or FB, but using a common standard instead of giving under-the-hood access to a corporate datafarm, and without losing ownership of comments on your platform. Also, some of the AP apps are, like DreamWidth, more oriented towards long-form writing (eg Hubzilla, Known, Plume), and there is also potential for enabling DreamWidth users to follow and be followed by blogs on other services, the same way we can with other blogs hosted on DreamWidth.

@rshatch

This comment has been minimized.

Copy link
Contributor

rshatch commented Dec 14, 2018

I think we'd be interested in it, but do you have any more details on implementation? The ActivityPub site seems to mostly link to the W3C spec which is... a bit abstract, heh.

@rshatch

This comment has been minimized.

Copy link
Contributor

rshatch commented Dec 14, 2018

Okay, I dug around some and it seems like it's mostly an API spec to implement (with a handful of other requirements alongside) - it may be best left until we have our REST API going first, so we can reuse some of the code there. Some write-ups I found that were enlightening:
https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/
https://github.com/dret/activitypub/blob/master/implementation.md

@strypey

This comment has been minimized.

Copy link
Author

strypey commented Dec 15, 2018

I'm an enthusiastic user and advocate of federated tech, not really an implementer, so I don't know of any other resources offhand. But I have asked the fediverse for suggestions, see here:
https://pinafore.social/statuses/101243595706059936

I maintain a watchlist of apps that have implemented AP (or are planning to), with links to the issue pages where they discuss their implementations. In case that helps?
https://gitlab.com/fediverse/fediverse.gitlab.io/wikis/watchlist-for-activitypub-apps

@kaniini

This comment has been minimized.

Copy link

kaniini commented Dec 17, 2018

my suggestion would be to write the code which exposes dreamwidth posts as valid AS2 objects first, as well as the user objects. try importing them into Pleroma and Mastodon in order to validate the AS2 objects. I especially recommend testing with Pleroma because it has an extensive AP debugger: we are in the process of trying to formally prove the security & robustness properties of our stack.

after that, you'll need to write an inbox handler to handle the subscriptions, comments, announces (boosts, reblogs, whatever).

finally, to bring it all together you'll need to write a service to handle the publishing (to other endpoints).

@LWFlouisa

This comment has been minimized.

Copy link

LWFlouisa commented Dec 17, 2018

So is the question about federating Dreamwidth, or implementing Mastumblr and Pleroma as comments? OK here we go, I want to see the Mastodon/pleroma comments thing included. Would be a lot better than trying to use Orbit chat for comments, maybe a bit easier to moderate.

@kaniini

This comment has been minimized.

Copy link

kaniini commented Dec 17, 2018

Once you have the parts for one, you basically have the same parts for the other, so it's really both ideally. As for federated comments on Dreamwidth that comes down to what filtering capabilities already exist in Dreamwidth, moderating them could be much more complicated at first :)

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 17, 2018

agree that the first thing to work on here is rendering dreamwidth models into ActivityStreams json. happy to give implementation advice/work through specifics either here or in #socialcg on irc.w3.org

@wohali

This comment has been minimized.

Copy link
Contributor

wohali commented Dec 18, 2018

I'd like to leave a warning that Mastodon/Pleroma's implementation of "follower only" leaves much to be desired vs. our circle system. Be careful.

@strypey

This comment has been minimized.

Copy link
Author

strypey commented Dec 18, 2018

Can you expand on the technical details of this @wohali ? It might be worth looking at the way Hubzilla and Osada implement AP, as their native federation standard (Zot) also involves a much more granular permissions system, but they have found ways to connect to AP networks without compromising their security model.

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 18, 2018

I can expand on the technical details of implementing a fine-grained permission system in ActivityPub:

Each activity has an "audience", and you send it to servers that are in that audience. The audience of an activity can be completely customized by the implementor, and it can consist of both arbitrary groups and individual users. Mastodon uses the built-in "followers" collection to address followers-only activities, but there's no requirement to do so, it just happens to fit our desired semantics. (which are designed to be lightweight and familiar to twitter users). You also don't need to make an audience public—like email, if the sending server deliver an activity directly to an individual account's inbox, it's for them. This method doesn't let you take advantage of the speedups for using a sharedInbox though.

To sum up, there are two main methods of implementing activity visibility in ActivityPub:

  • Explicitly address it to accounts or custom groups of accounts that you wish to be able to see the post, and then deliver it to the sharedInbox of the set of servers those accounts reside on. This is a significant speedup for delivery when lots of your followers/people in your circles share the same servers, but it requires the addressing of a post to be visible to the people receiving it (for example, it would require circles to be visible to the users in them). This is (to the best of my knowledge) the method that hubzilla uses, and also the method that mastodon uses when sending posts.

  • Don't address it, or address it to groups that aren't visible to other users (so for example, someone could see that it was posted to the "knitting" circle but not who received it), and then send it individually to the inbox of each account. (this, since it is more fully general, is the method that Kroeg uses)

Mastodon now supports receiving posts with both methods (although there may be some bugs with actually dereferencing publicly visible groups since afaik no one is currently sending posts like that, hubzilla lists out all accounts being addressed)

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 18, 2018

From a broad perspective, I would say there are two main things to implement when writing a federated server:

  • Sending posts: When a user makes a post, you need to deliver it to all of their remote followers as well, by POSTing an authenticated as2 representation of it to their inboxes or sharedInboxes. This also requires changes to the model classes to represent the concept of a "remote" account as well as the required information necessary for sending (the url of that account, the url of it's inbox). For remote servers to be able to read your posts, they'll also need to be able to fetch an as2 representation of the account sending the post.

  • Receiving posts: Users should be able to 1) find remote accounts, 2) subscribe to remote accounts 3) view the posts made by remote accounts when they're sent to your server. This requires implementing both an "inbox" endpoint for remote servers to send activities to and a way to fetch arbitrary accounts.

This is just a high level overview, I don't know a ton about dreamwidth's internals so I don't have a good sense of how to break this up into small and meaningful units of work. Definitely let me know if you have any questions though! I've worked on the AP implementation for Mastodon and have helped a lot of people debug their AP impls and get off the ground with federation, and would love to see dreamwidth federating.

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 18, 2018

It looks like DW already has a concept of external accounts for RSS feeds/etc—i haven't looked into it in too much detail, but this may fit very nicely within that framework.

@wohali

This comment has been minimized.

Copy link
Contributor

wohali commented Dec 18, 2018

My point @strypey is what @nightpool said:

Each activity has an "audience", and you send it to servers that are in that audience. The audience of an activity can be completely customized by the implementor, and it can consist of both arbitrary groups and individual users.

This could be abused by a malicious actor with a remote ActivityPub implementation to leak posts that are supposed to be limited to a DW user's access list.

A good analogy is that, in Mastodon, marking a post as "followers-only" is a convention only respected by Mastodon servers (and a few other implementations at this point). There is absolutely nothing in the protocol that actually prevents those posts from being seen by non-followers of an account on another server as long as that server is federated with the poster's server.

I would be very unhappy if posts marked in DW as "Access List only" were able to be leaked to the Fediverse as "follower-only" posts. There is a significant enough "impedance mismatch" between what DW means in terms of privacy and what federation does for privacy, where a single entity (DW Inc.) is not in control of the entire platform.

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 18, 2018

@wohali I don't think it's accurate to call it a convention—that was certainly true when mastodon was using ostatus, but had not been true for nearly a year and a half now.

email has exactly the same privacy model, but you never see people worried that their email provider is going to show their mail to the wrong people.

@wohali

This comment has been minimized.

Copy link
Contributor

wohali commented Dec 19, 2018

@nightpool All I'm asking for here is some care - and the option to not publish private/access list content to ActivityPub if a user chooses to opt out of such a thing. This is very much in keeping with DW's privacy-first model.

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 19, 2018

@wohali

This comment has been minimized.

Copy link
Contributor

wohali commented Dec 19, 2018

@nightpool I still think it's accurate to say that you can implement ActivityPub and not respect the concept of "Follower Only", and that's outside of the hands of DW developers.

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 19, 2018

@wohali

This comment has been minimized.

Copy link
Contributor

wohali commented Dec 19, 2018

I'm out, you're intentionally avoiding my issue.

Carry on without me, I've lost interest.

Just remember the "bad actor" user model and think about the possible ramifications. Admins in the fediverse can read all messages that go through them. They could then expose them to third parties.

@strypey

This comment has been minimized.

Copy link
Author

strypey commented Dec 19, 2018

@wohali

All I'm asking for here is some care - and the option to not publish private/access list content to ActivityPub if a user chooses to opt out of such a thing.

That's totally reasonable :-) My suggestion would be for Dreamwidth to federate only public-facing blogs and comments to the fediverse. Federating private content could be considered later, when the privacy implications are better understood, but actually I think it's reasonable to ask users to set up a Dreamwidth account if they want to take part in the private side of the Dreamwidth community. I do think it would be a win-win for the network effect of both Dreamwidth and the fediverse to federate content that Dreamwidth already publishes to the open web, and allow fediverse users to follow and comment on Dreamwidth blogs (with the blog owner's approval).

@nightpool

I could also implement an email server that showed every user's post on the front page

At the risk of drifting a bit off-topic, here's someone actually doing that, as a way of managing blog comments:
https://lists.sr.ht/~sircmpwn/public-inbox

@nightpool

This comment has been minimized.

Copy link

nightpool commented Dec 19, 2018

Sorry if it felt like i was trying to intentionally avoid your issue—i sincerely wasn't, I believe that the privacy-first model is really important. I was just trying to explain by analogy why I believe, from experience, that the technical risks of a non-compliant implementation are offset by both social and technical corrective forces.

@frandroid

This comment has been minimized.

Copy link

frandroid commented Dec 19, 2018

the option to not publish private/access list content to ActivityPub if a user chooses to opt out of such a thing. This is very much in keeping with DW's privacy-first model.

A privacy-first model would make publishing to ActivityPub an opt-in, not an opt-out.

@rshatch

This comment has been minimized.

Copy link
Contributor

rshatch commented Dec 19, 2018

Given that it seems like implementing ActivityStreams that can be read by basically all servers requires maintaining a key-pair for the originating account, it would almost certainly be opt-in only - there are over 3 million registered accounts, and that is a lot of accounts to store and manage keys for, honestly.

Handling access-control is a more complicated matter because it looks like there's no real widely used successor to OpenID? And I'm not sure we're even using the latest implementation for that, given the usage is so low. But that said - we do have the concept of external site accounts in OpenID, and mechanisms for integrating them with DW access controls, and we do have the concept of interacting with external accounts in the form of feed accounts already.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment