-
-
Notifications
You must be signed in to change notification settings - Fork 889
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
Implement instance actor #1798
Conversation
311200b
to
eac0348
Compare
b8daa56
to
4b0dbdf
Compare
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 |
4b0dbdf
to
d7a9584
Compare
d7a9584
to
e7a0675
Compare
crates/api_common/src/community.rs
Outdated
/// 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>, |
There was a problem hiding this comment.
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.
Tests failing for some reason. |
e7a0675
to
9e3fbae
Compare
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. |
94e7ae3
to
02eee1c
Compare
There was a problem hiding this 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) => { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
#[derive(Clone, Debug, Deserialize, Serialize)] | ||
#[serde(rename_all = "camelCase")] | ||
pub(crate) struct PersonOutbox { | ||
pub(crate) struct EmptyOutbox { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whats going on here.
There was a problem hiding this comment.
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).
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) |
There was a problem hiding this comment.
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.
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(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good.
38481b9
to
238dc11
Compare
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. |
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. |
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. |
6e56ce0
to
0dad9a6
Compare
* 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
This will allow us to federate things like instance description and site bans. It is also a prerequisite for #1487.
Todo: