Project

General

Profile

Feature #3333

support authentication against diaspora

Added by Pirate Praveen about 2 years ago. Updated over 1 year ago.

Status:
Feedback
Priority:
High
Target version:
Start date:
2015-07-30
Due date:
2016-06-30
% Done:

0%

Database:
n/a
Source Code Disclaimer:
Additional charges approved:
No
Releases:

Description

Kontalk messaging network is built on tigasse, diaspora social network has support for prosody and vines. We run two diaspora pods, diasp.in and poddery.com, and want to offer kontalk from the same server. This was discussed with kontalk developers and they suggested tigase is the right place https://github.com/kontalk/tigase-server/issues/7

Here is how prosody integrates diaspora https://wiki.diasporafoundation.org/Integration/XMPP/Prosody

Diaspora authentication for tigase would make tigase a candidate xmpp provider for 100+ diaspora pods, it will also encourage them to offer a kontalk service too.

History

#1 Updated by Artur Hefczyc about 2 years ago

  • Due date set to 2015-08-07
  • Assignee set to Andrzej Wójcik
  • Target version set to tigase-server-7.1.0

Andrzej, please estimate work required to add Diaspora authentication support in Tigase.

#2 Updated by Andrzej Wójcik about 2 years ago

  • Status changed from New to Feedback
  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

Looking at code from https://gist.githubusercontent.com/jhass/948e8e8d87b9143f97ad/raw/mod_auth_diaspora.lua, this task looks rather simple to add authentication module to Tigase XMPP Server to support authentication against diaspora.

However we have 2 things which can cause problems:
  • creation of test installation of Diaspora (to verify that implementation works properly)
    This is something which needs to be learned
  • bcrypt - passwords stored by Diaspora are encrypted using bcrypt salted hashing algorithm
    bcrypt algorithm is not supported by JDK, so we would need to add external library as dependency (see jBCrypt) or include bcrypt implementation from other opensource project (maybe from SpringSecurity)
    In both cases we need to check if there will be any licensing issues with using this.
    If we decide to use jBCrypt we need to add this library as dependency, so I would suggest creation of subproject with support for Diaspora (to be able to build core Tigase XMPP Server without this dependency).
    If we decide to use code from SpringSecurity then we could add this code directly to Tigase XMPP Server and no additional subproject would be needed. However we would need to fix issues with this code if any will appear.

Assuming that we would be able to use existing implementation of bcrypt I think we should be able to implement this in 32h (maybe less) including creation of installation of Diaspora for development.
This estimated time is only for support of authentication against Diaspora if it will use external database (ie. MySQL, and not SQLite3). It do not include implementation of roster based on Diaspora contacts (as implemented here for Prosody)

#3 Updated by Pirate Praveen about 2 years ago

Andrzej Wójcik wrote:

However we have 2 things which can cause problems:
  • creation of test installation of Diaspora (to verify that implementation works properly)
    This is something which needs to be learned

I have created a debian package and its as easy as apt-get install and answering a few questions https://tracker.debian.org/pkg/diaspora-installer

https://people.debian.org/~praveen/diaspora-jessie/

This estimated time is only for support of authentication against Diaspora if it will use external database (ie. MySQL, and not SQLite3). It do not include implementation of roster based on Diaspora contacts (as implemented here for Prosody)

This would be needed as well because contacts are primarily handled by diaspora.

#4 Updated by Andrzej Wójcik about 2 years ago

I initially excluded support for "contacts" integration as it was only authentication against Diaspora mentioned.

However looking at implementation of "contacts" integration between Prosody and Diaspora I would say it may add additional 40h as this integration looks tricky to be added due to current internal implementation of processing requests of roster, etc. in Tigase XMPP Server.
We would need to add:
  • injection of roster contacts from outside of Tigase XMPP Server database
  • ability to add periodical synchronization of external roster from Diaspora database

both require changes to internal Tigase XMPP Server API.

#5 Updated by Artur Hefczyc about 2 years ago

Andrzej, for this kind of contacts integration we normally use DynamicRoster API. It allows Tigase to directly load roster data from non-Tigase data storage. Tigase cannot change items in the dynamic roster but this is good enough for most use cases and I think should be enough for Diaspora integration. This way we would also avoid DB synchronization. Do you think this is possible?

#6 Updated by Artur Hefczyc about 2 years ago

  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

#7 Updated by Andrzej Wójcik about 2 years ago

  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

I think we could use DynamicRoster API, however any changes of contacts in Diaspora will not be visible for user until reconnection, as Tigase will keep in memory older version. Prosody had same issue, and they synchronize roster/dynamic roster with database every 5 minutes. To have similar integration and be able to refresh contacts list when user in Diaspora change this list, we need to have some way to add periodical synchronization.

#8 Updated by Artur Hefczyc about 2 years ago

  • Due date changed from 2015-08-07 to 2015-12-31

Andrzej, thank you for the additional information.

I am generally against such periodic synchronization because I always have in mind installation with 1M or more online users. Synchronizing roster every now and then means we would have 1M or more DB calls on regular basis. Most of them would be unnecessary as most users do not change their contact list often. So we would generate huge load for nothing.

A better way would be to provide an ad-hoc command (REST API) to call when a user's roster needs update/sync. The command could even contain all the info so Tigase would not need to call DB. That would be much more efficient and users would get roster update instantly.

But, ok, I get the idea of the work required and we may work on it at some point.

#9 Updated by Artur Hefczyc about 2 years ago

  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

#10 Updated by Artur Hefczyc about 2 years ago

  • Due date changed from 2015-12-31 to 2016-06-30
  • Target version changed from tigase-server-7.1.0 to tigase-server-7.3.0

#11 Updated by Andrzej Wójcik over 1 year ago

  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

#13 Updated by Artur Hefczyc over 1 year ago

  • Assignee changed from Artur Hefczyc to Bartosz Malkowski

I am assigning this to our expert. Bartek what do you think?

Also available in: Atom PDF