This was pretty big and hard to follow, but I think I follow... its mostly extracting things from the shared inbox / other inboxes to the activity receive folders.
This was pretty big and hard to follow, but I think I follow... its mostly extracting things from the shared inbox / other inboxes to the activity receive folders.
Follow should probably be separate from the other communityvalidtypes... this is why we had the shared inbox be all public activities, and the user and community inboxes only be the private activities , following / unfollowing, sending a dm, etc.
Follow should probably be separate from the other communityvalidtypes... this is why we had the shared inbox be all public activities, and the user and community inboxes only be the private activities , following / unfollowing, sending a dm, etc.
Well the reason I split the inboxes is because it makes no sense to handle a Create/Post identical to an Announce/Create/Post, they are quite different things. For example it is much easier to implement community bans now.
Anyway I'm rewriting this in a better way.
Well the reason I split the inboxes is because it makes no sense to handle a `Create/Post` identical to an `Announce/Create/Post`, they are quite different things. For example it is much easier to implement community bans now.
Anyway I'm rewriting this in a better way.
What do you think about separating the websocket notifications like this? It seems more logical to me to separate it from the receive logic, but most likely its too complicated cause every type of activity would have to be handled separately anyway.
What do you think about separating the websocket notifications like this? It seems more logical to me to separate it from the receive logic, but most likely its too complicated cause every type of activity would have to be handled separately anyway.
As I said, the test case A and G subscribe to B (center) A posts, G mentions B, it gets announced to A needs to be fixed, then it can be squashed and merged.
I also added a check to ensure that post, comment etc activities are addressed to public. This is to prevent the possibility of communities announcing private activities (eg private message) which they received by accident (or due to bugs).
By the way, we could merge the code for user_inbox, community_inbox and shared_inbox functions even more, because they are mostly identical.
As I said, the test case `A and G subscribe to B (center) A posts, G mentions B, it gets announced to A` needs to be fixed, then it can be squashed and merged.
I also added a check to ensure that post, comment etc activities are addressed to public. This is to prevent the possibility of communities announcing private activities (eg private message) which they received by accident (or due to bugs).
By the way, we could merge the code for user_inbox, community_inbox and shared_inbox functions even more, because they are mostly identical.
Squashed this and fixed a bug in community removal. Still need to fix the test A and G subscribe to B (center) A posts, G mentions B, it gets announced to A (which I dont understand).
Squashed this and fixed a bug in community removal. Still need to fix the test `A and G subscribe to B (center) A posts, G mentions B, it gets announced to A` (which I dont understand).
nutomic
changed title from WIP: Separate logic for user and community inbox to Separate logic for user and community inbox3 months ago
Just pushing what I have so far. Still very much WIP.
Let me know if there's anything I can do for this.
Seems good to move this here.
This was pretty big and hard to follow, but I think I follow... its mostly extracting things from the shared inbox / other inboxes to the activity receive folders.
Its fine to me.
is_addressed_to seems fine to me, otherwise maybe
extract_local_community_from_to_and_ccs
or something.Thanks, I went with
extract_local_community_from_destinations()
and changed the others to return bool.Follow should probably be separate from the other communityvalidtypes... this is why we had the shared inbox be all public activities, and the user and community inboxes only be the private activities , following / unfollowing, sending a dm, etc.
Well the reason I split the inboxes is because it makes no sense to handle a
Create/Post
identical to anAnnounce/Create/Post
, they are quite different things. For example it is much easier to implement community bans now.Anyway I'm rewriting this in a better way.
What do you think about separating the websocket notifications like this? It seems more logical to me to separate it from the receive logic, but most likely its too complicated cause every type of activity would have to be handled separately anyway.
As I said, the test case
A and G subscribe to B (center) A posts, G mentions B, it gets announced to A
needs to be fixed, then it can be squashed and merged.I also added a check to ensure that post, comment etc activities are addressed to public. This is to prevent the possibility of communities announcing private activities (eg private message) which they received by accident (or due to bugs).
By the way, we could merge the code for user_inbox, community_inbox and shared_inbox functions even more, because they are mostly identical.
Squashed this and fixed a bug in community removal. Still need to fix the test
A and G subscribe to B (center) A posts, G mentions B, it gets announced to A
(which I dont understand).WIP: Separate logic for user and community inboxto Separate logic for user and community inbox 3 months ago437809d337
.