Skip to content
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

Implement instance actor #1798

Merged
merged 8 commits into from
Feb 7, 2022
Merged

Implement instance actor #1798

merged 8 commits into from
Feb 7, 2022

Conversation

Nutomic
Copy link
Member

@Nutomic Nutomic commented Sep 28, 2021

This will allow us to federate things like instance description and site bans. It is also a prerequisite for #1487.

Todo:

  • write db migrations
  • fetch the instance actor when parsing a remote community (make it optional if possible for compatibility)
  • implement site inbox/outbox
  • create api for retrieving info for remote instances
  • write federation test

@Nutomic Nutomic marked this pull request as draft September 28, 2021 16:09
@Nutomic Nutomic force-pushed the instance-actor branch 2 times, most recently from 311200b to eac0348 Compare September 30, 2021 17:56
@Nutomic Nutomic mentioned this pull request Oct 1, 2021
@Nutomic Nutomic force-pushed the instance-actor branch 7 times, most recently from b8daa56 to 4b0dbdf Compare February 1, 2022 21:16
@Nutomic
Copy link
Member Author

Nutomic commented Feb 1, 2022

This is almost finished, just need to get the api tests working and do some manual testing. There are no breaking changes, so we can simply release it in 0.15.3

/// default values. May be null if the community is hosted on an older Lemmy version, or on
/// another software.
/// TODO: this should probably be SiteView
pub site: Option<Site>,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasnt sure whats the best way to expose this data over the api. Anyway its not needed for federated bans, so i can just remove it and implement it properly later. The main purpose is to show the instance sidebar (with rules etc) when browsing a remote community.

@Nutomic Nutomic marked this pull request as ready for review February 1, 2022 21:35
@Nutomic Nutomic requested a review from dessalines as a code owner February 1, 2022 21:35
@dessalines
Copy link
Member

Tests failing for some reason.

@Nutomic
Copy link
Member Author

Nutomic commented Feb 7, 2022

Fixed api tests. Also removed site from GetCommunityResponse, because it was badly implemented. We should do that later, so that the sidebar/rules of remote instance can be displayed when browsing a remote community.

So this is ready to review/merge/release.

Copy link
Member

@dessalines dessalines left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, my only thing is due to the changes in the site table that will require additions to lemmy-js-client, and possibly apps, that we merge but push this to the next release. Also it'll need some testing.

My main question and what we need to test: This will only federate the bans and removes from the host instance, correct?

IE if enterprise bans and removes content from someone that lives on ds9, the deletes and bans should not be federated to DS9.

But if the user lives on enterprise, then that ban and deletes should be federated elsewhere.

verify_domains_match(&site.actor_id(), self.actor.inner())?;
verify_domains_match(&site.actor_id(), self.object.inner())?;
}
SiteOrCommunity::Community(community) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have to worry about this in this PR, but something tells me there's a better / more generic way to do these SiteOrCommunity and PostOrComment enums, maybe @asonix has some ideas.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you don't want to keep re-defining two-variant enums you could use a single Either<L, R> type instead

crates/apub/src/http/site.rs Show resolved Hide resolved
crates/apub/src/objects/comment.rs Show resolved Hide resolved
#[derive(Clone, Debug, Deserialize, Serialize)]
#[serde(rename_all = "camelCase")]
pub(crate) struct PersonOutbox {
pub(crate) struct EmptyOutbox {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats going on here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just changed the name, because this is used both by Person and Site now. So the old name wouldnt make much sense. Only functionality change is how the outbox url is generated (because site does that differently).

crates/apub/src/protocol/mod.rs Show resolved Hide resolved
Comment on lines +58 to +60
pub fn read_remote_sites(conn: &PgConnection) -> Result<Vec<Self>, Error> {
use crate::schema::site::dsl::*;
site.order_by(id).offset(1).get_results::<Self>(conn)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I like this, it'll be useful for other things.

crates/db_schema/src/source/site.rs Show resolved Hide resolved
add column last_refreshed_at Timestamp not null default now(),
add column inbox_url varchar(255) not null default generate_unique_changeme(),
add column private_key text,
add column public_key text not null default generate_unique_changeme();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good.

crates/api_crud/src/site/create.rs Show resolved Hide resolved
@Nutomic
Copy link
Member Author

Nutomic commented Feb 7, 2022

My main question and what we need to test: This will only federate the bans and removes from the host instance, correct?

IE if enterprise bans and removes content from someone that lives on ds9, the deletes and bans should not be federated to DS9.

But if the user lives on enterprise, then that ban and deletes should be federated elsewhere.

Correct, site bans are only federated if they are made on the user's home instance. Actually i forgot to check for that, but added the check now.

I dont think additional fields are considered a breaking change, as they are generally ignored. And if not, that would be easy enough to change in the client.

@dessalines
Copy link
Member

Correct, site bans are only federated if they are made on the user's home instance. Actually i forgot to check for that, but added the check now.

Could you also add a federation test for that? Seems important to make sure admins can't mess with other instances.

@Nutomic
Copy link
Member Author

Nutomic commented Feb 7, 2022

Such a test wouldnt be effective. As you can see in my second to last commit, the activity isnt even sent when its a remote user. The same is true with most other malicious activites, Lemmy prevents sending them (but other software still can).

So to test for that, we would need another test suite that eliminates the sending Lemmy instance from the equation. The easiest way would be to store activities as json files in the repo, and POST them to Lemmy directly with curl, then check that the expected action was (not) taken.

@dessalines dessalines enabled auto-merge (squash) February 7, 2022 19:10
@dessalines dessalines merged commit dd865c5 into main Feb 7, 2022
dessalines pushed a commit that referenced this pull request Feb 7, 2022
* Implement instance actor

* wip: make site bans federate

* finish implementation and unit tests for federated bans

* start adding api tests

* fix api test

* remve site from GetCommunityResponse

* only federate site bans originating from user's home instance

* dont expose site.private_key in api
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants