Specification: DjangoLDP -> Prosody notifications format & conditions

Notification format

Following LDN:

{
  '@context': 'https://cdn.happy-dev.fr/owl/hdcontext.jsonld',
  object: 'http://server/model/resource/',
  author: 'http://server/users/.../',
  type: 'update'
}

Where:

  • @context: May contain a local or link to an external JSON containing the terms that are used throughout the document.
  • object: @id of the resource that have been modified
  • author: @id of the person who did the modification
  • type: Can be any of creation, update, deletion

Notice: In case of a deletion, the object will be a 404.

Actual subscriptions

DjangoLDP subscribe those containes to those Prosody endpoints:

  • server/users/ -> prosody/domain/happydev_user_admin
  • server/projects/ -> prosody/conference.domain/happydev_muc_admin
  • server/circles/ -> prosody/conference.domain/happydev_muc_admin
  • server/profiles/, field=user -> prosody/domain/happydev_user_admin
  • server/accounts/, field=user -> prosody/domain/happydev_user_admin
  • server/chatprofiles/, field=user -> prosody/domain/happydev_user_admin

Where:

  • server: URL of the DjangoLDP server
  • prosody: jabber.happy-dev.fr or xmpp-dev.startinblox.com
  • domain: is the vhost for Prosody & the domain part of the jabberid which DjangoLDP will use
  • field stands for the resource that'll get sent as object when something happen on the model

When does each subscription triggers

server/users/

Any modification related to first_name, last_name, email, username, fullname

server/profiles/

Any modification related to job, city, phone, website

Does trigger a notification with server/users/xyz/ instead of /profiles/xyz/

server/accounts/

Any modification related to picture

Does trigger a notification with server/users/xyz/ instead of /accounts/xyz/

server/chatprofiles/

Any modification related to jabberID

Does trigger a notification with server/users/xyz/ instead of /chatprofiles/xyz/

server/circles/

Any modification related to name, subtitle, description, status, jabberID, jabberRoom, owner, members

  • jabberRoom should always be True
  • owner is the person who own the circle on a SOLID perspective
  • owner is always a member, and have is_admin: True
  • Does not include members by themselves, only a list of relation to them.
  • Each members have circle, user, is_admin and will trigger the notification for the circle too

server/projects/

Any modification related to name, description, status, number, jabberID, jabberRoom, customer, captain, members

  • jabberRoom should always be True
  • captain is the person who own the circle on a SOLID perspective
  • captain is always a member, and have is_admin: True
  • Does not include members by themselves, only a list of relation to them.
  • Each members have project, user, is_admin and will trigger the notification for the circle too

Suggested changes

To improve stability and performence between Prosody & DjangoLDP, I suggest to change the list of subscriptions this way:

  • server/users/ -> prosody/domain/startinblox_user_admin
  • server/accounts/, field=user -> prosody/domain/startinblox_user_admin
  • server/chatprofiles/, field=user -> prosody/domain/startinblox_user_admin
  • server/projects/ -> prosody/conference.domain/startinblox_muc_admin
  • server/circles/ -> prosody/conference.domain/startinblox_muc_admin
  • server/project-members/ -> prosody/conference.domain/startinblox_muc_members_admin
  • server/circle-members/ -> prosody/conference.domain/startinblox_muc_members_admin

Where:

  • happydev -> startinblox is a fancy rename, it'll ensure that configuration are properly updated on every DjangoLDPs'
  • startinblox_muc_admin will only manage Circle/Project creation, update & deletion and will not deal with the member list
  • startinblox_muc_members_admin will manage association between a Circle/Project and their members, it'll also be used to define who is administrator

Deletion

Deletion of an user membership or of a circle may need some caching from Prosody to associate properly who is associated to what by their urlid instead of their jabberid.

When something is deleted, its object will be a 404, still Prosody will receive a notification for related objects.

Security note

Only domain should be allowed to send notifications to prosody/domain/startinblox_* and prosody/conference.domain/startinblox_*.

Questions

@MattJ Would it be easier for you to deal separatly with Project & Circle as they're using different path to reach them from the membership? If so, we can imagine startinblox_project_admin, startinblox_project_members_admin, same for circles, instead.

@MattJ Personal curiosity here. How do you deal with those modules when using multiple Prosody servers? Like say the user is not known from the Prosody hosting the MUC, does it share informations about urlid, does it have to request it by itself - and so may not get authenticated properly - or does it fail?

Estimations

  • Adapt create_subscriptions on djangoldp-notification: 12 tokens
  • Prosody modules: 50 tokens by @manv
  • Deploy the new configuration properly on stagings then on productions: 12 tokens
  • Specification, testing and fancy things like keeping @alex serene (:-)): 24 tokens

Total 98 tokens

Related #17 (comment 52564)

Edited by Jean-Baptiste Pasquier