Backlinks collision on /user/inbox/

DjangoLDPNotifications provides an inbox of notifications on a nested field of the user model /inbox/

Changes to DjangoLDP to support backlinks & ActivityStreams will use this url as a POST and GET for a user's Activities

I propose that DjangoLDPNotifications should be rolled into this, and the current uses of it should be refactored to use ActivityPub.. @jbpasquier you understand DjangoLDP-Notifications better than me, is this correct, and do you know how it will impact HubL's chat feature (or another client)?

mentioned in issue management/core-team#3

It's perfectly fine to keep use /inbox/ for notifications, Notification component should filter what it'll show based on the Type of them.

I'm not sure if we're talking about the same thing

GET /users/admin/inbox returns 405 at the moment, but should later return the Activities associated to the user admin's inbox (djangoldp#196 (closed))

Possible solutions are:

• DjangoLDP-Notification's functionality becomes a part of DjangoLDP using Activity
• Notification is refactored to use Activity model or extend it, but remains in its own package

What do you think? I'm inclined to the second option but I haven't used DjangoLDP-Notification too much

There may be no difference between an inbox of a resource and an inbox of an user right?

So, we're by default on the first case. But, we still need to keep DLDP-notifications to handle subscriptions & all things that are currently not implemented on AS/AP part of DjangoLDP, so we're also on the second solution.

I'm not sure to understand but what you are saying @calummackervoy is that the /inbox path already exists on user and you would like to remove it to use the same thing than for other resources?

What does it involve for the front-end then?

@matthieu the issue is about the backlinks using /inbox/ to GET/POST ActivityStream Activities, whilst currently DjangoLDP-Notification uses inbox also but storing Notification objects

Scoping the changes I would need to change the Notification model to extend Activity, and the format of requests to be compatible with ActivityStreams format. It will probably affect the front-end in the sense that some field names have changed, but shouldn't affect it apart from this

Notifications are mostly used in chat, right? Who is the person (backend) that I should consult about this?

Notifications from chat are sent by Prosody there https://git.startinblox.com/infra/prosody-modules/blob/master/mod_happydev_muc_notify.lua#L33-40 for MUC and there https://git.startinblox.com/infra/prosody-modules/blob/master/mod_happydev_user_notify.lua#L26-32 for o2o.

The person in charge for this part is @MattJ.

Beware, as we've only one server for all productions and all testing instances, that mean that migration will break the other. We must sync when we'll need to deploy this new version and can't test it properly.

Good news is that's only a JSON, as long as we can post it with curl and rewrite the one sent by Prosody, it'll works the exact same way.

For client-side adaptation, it'll be @matthieu I guess. :-)

And for the DjangoLDP part, as we have no other Matt' it's all yours. :) I can provide some help here if needed.

For client-side, I confirm, just let me know what you change ;)

For now it's not a necessity that we can GET the activities on a user's inbox, so I've changed the working of backlinks so that each server has only one inbox (meaning this isn't a problem for the 7th May MVP release)

I think that at some point it would be good to offer users inboxes for their activities, so we should keep this issue open? But maybe it's not a priority

If I understood correctly, it means no change on sib-notifications for now?

yes exactly

So, no change on Prosody too, right?

Not sure to understand why/how each server have only one inbox though, but as long as it works...

yeah no changes needed for now

the inbox is only used to POST a backlink activity for the moment (the target is specified by the target field rather than the inbox location)

this will need to change when we want to support GET activities for specific inboxes

Sure, as the target inbox's owner/resource is not always the target field of an activity.

When Bob actor mention type you to.id/object on Sib Contributor target. Here, it should goes from the Sib Contributor's outbox to your inbox. We could even goes more verbose, because you can mention someone from another channel to another (#channel), here it'll also need an origin.

closed

mentioned in issue djangoldp#332