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 beTrue
-
owner
is the person who own the circle on a SOLID perspective -
owner
is always a member, and haveis_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 beTrue
-
captain
is the person who own the circle on a SOLID perspective -
captain
is always a member, and haveis_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)