I agree with all @Smag0
Let’s say user A is the user writing the post. User B is the one commenting.
Yes, User B comments should be User B pod. Yes it makes sense to add a link to this comment on User A POD so that we could easily show user A post + all comments from all other users. User B does not necessarilly has acl to access the user A POD and store a link to his comment. Or should he ?
In all cases : the links to comments for a given post could be in a separated file / ressource so that ACL can be on this index file rather than on the post file.
Two scenarios :
- You need to be friend to comment on a user post, in which case we can imagine give proper acl access to user B to the comments index file on User A post so that he can add link to his comment. However : we would need granular ACL so that user B does not have access to mess up with all other users comments ! Is it possible ?
- Anyone can comment a user post, in which case wouldn’t it make sense to give public access to the index file ? but still … some kind of granular access would be required. Some kind of special ACL that can isolate the date of each webuserid initiating it. Is it possible ?
And even then, is the question of data ownership : yes actual data (the comment) stays on the pod of the user having done the comment. However there is some kind of “personnal data” that is stored on another user pod : the actual fact that user B commented on user A pod. We don’t have the content, but the action. To me it is ok, and storage is limited at one level only, on User A pod, not on a central location.
3rd scenario:
This is a specific case where it could make sense to have a third party, responsible for tracking these indexes (tracking links in both direction, for efficiency purposes) , a server side level for handling this and making all of this efficient, but yes this bring the question of trusting a central “authority”
Humm notification to the inbox of user A could be a nice idea. And then he has to accept the comments. Or : whenever he connects to the application, all inbox messages are automatically processed. Which means that all other users will see an up to date list of comments on User A post only after User A will connect … Notifications to be added also for deletion of comments, but less important. What could make for this scenario : having some kind of “batch processing” capacity on solid servers, where a user can register a batch that could run on his behalf, even if he is not connected, and run on a regular basis or on a trigger (ex : message received in inbox). Is this possible ?
This is a common scenario, it is worth having a design pattern for this. I am hoping to get some answers / ideas in the decentralization workshop about decentralization patterns : https://decentpatterns.xyz/virtual-workshop-cyan/
And then the idea is to automate the implementation of these patterns so that it does not have to be manually coded every time ! I will post a demo soon on how we can do this with Generative Objects low code platforme GO-Lowcode
About the wall : I am not sure I see the point of the wall. In my demo, I am directly showing the post form user A post storage on user A pod. Why using and extra concept of a wall ?