@kobit I think that this could be useful also in the Kangaroo project to comply with GDPR.

+1

Do you need anything from my side for this to work on?

@kobit I just wanted to suggest an idea and confirm that it is not something that we will not need or want.

I can think about 2 things. We would need to:

1. find a "way" to inform the XMPP server that the privacy policy has (or will) change I suppose ad-hoc could work just fine
2. have a stable HTTPS URL for users to access our privacy policy That will be required later on when we would like to deploy.
3. decide if we want it in standard as a feature which when configured could be enabled I would say yes.

@bmalkow @wojtek Could you review the general idea of how it would work and give me your opinions about it?

@andrzej.wojcik I think the general idea is sound. Couple of comments: a. possibly make it configurable on per-vhost basis (this may be quite iffy) b. have set of pre-configured policies (version + link where it's available as I would assume it would be external and very static), managed in the repository so that we would be able to select desired version, which would trigger requirement for user to re-accept

1. 2, 3: +1 from me

@wojtek

a. possibly make it configurable on per-vhost basis (this may be quite iffy)

What for? We are operators of this domain, so we are processing users data, not the vhost owner? or are we processing those data on vhost owners request?

b. have set of pre-configured policies (version + link where it's available as I would assume it would be external and very static), managed in the repository so that we would be able to select desired version, which would trigger requirement for user to re-accept

I was thinking about having a repository with date, id/sha of policy text/sha of policy file, link to correct version of a policy. Those would be managed by ad-hoc and could trigger notifications, etc.

a. possibly make it configurable on per-vhost basis (this may be quite iffy)

What for? We are operators of this domain, so we are processing users data, not the vhost owner? or are we processing those data on vhost owners request?

Ability to have different policies/versions, though in the light of KISS let's just skip that.

I was thinking about having a repository with date, id/sha of policy text/sha of policy file, link to correct version of a policy. Those would be managed by ad-hoc and could trigger notifications, etc.

+1

Actually, having a different policy for different vhosts might be quite handy. We might offer slightly different services for some users (vhosts) from others. For example, free offering might be different from paid. Then different policy terms make sense. I mean, we should have one default for all but with an option to assign a different policy if necessary for selected vhosts.

(private comment as it touches on Kangaroo) I was thinking about something similar but that would be helpful for multi-tenant installation (i.e. something like sure.im). However, for our other project we are aiming at dedicated instances, hence single policy for the installation should be sufficient? The questions are:

1. will we be supporting multi-tenant installations on Kangaroo (at first it was ruled out, but then in one of the email threads it was mentioned and AFAIR it was at least considered so I don't know the current perspective on this one)?
2. should we dedicate time to extend it if it would only be used on sure.im (i.e. no multi-tenant from (1))?

Changed issue visibility to Tigase Team only.

Yes, for the Kangaroo we will be offering accounts on "shared" system. That shared is multi-tenant as I understand it.

Except from Kangaroo, we might also offer some paid and free services like those on sure.im/tigase.im. Although at this point I have no specific vision on how to offer paid services for pure XMPP accounts.

So the conclusion on that point is that we should implement policies on per-vhost basis - correct?

Yes, that is my understanding.