Especially since the end of the crowdfunding I think a lot about our data-infrastructure and unsolved problems within it. My problem right now is account-managing.
We need an “Sign-up with your GCS-Account”-function. So we also need an external user-account-manager.
And a bit off-topic, but we also need an user-interface for a gcs-specific means-database
The users have to deal with different databases within the software. For example the software asks him/her, if he/she has a specific means and would share it with others / make it to a commons under
And also this means database could be cultivated by the user even if he/she does not (anymore) uses a specific GCS-App, but still wants to share his/her stuff. So other participants can perform activities with it or this person can borrow stuff from other persons, if they don’t mark that stuff for exclusive use for commoning - so pretty much the functionality of an ordinary means-database like depot.leipzig, but as free software and with the specific requirement of the gcs-infrastructure. So, if we need a external specific GCS-means-database (and I’m pretty sure, we need one), we need a stand-alone user-interface for it. But that is not my point right now.
But how does the gcs-specific database know that this specific user has the right to edit this specific item? And how does the software of the second app recognize the user?
But what about the second yet unknown gcs-app? I the user opens a new account, he/she does not have access to his/her own means. So he/she has to link the new account to the old one or - which seems to be more elegant - has the option to log in with your GCS-Account. And if he/she does that, all the relevant information are synced within the new app. Which pre-assumes there is an external account management tool, which has these information saved.
(red are additional information. They mean, that the gcs-specific means-database does not run through the means-database extractor/adapter (because they should be formatted for our purpose from the beginning) and the Engine needs the information of these databases to propose activities).
Of course we can use the same method with activity pattern databases. But how do we manage the syncronization of communication? The communication needs to work inside and outside specific apps. But that’s a problem for its own.
I found this list of FOSS-Identity-Managment-Tools: The 10 Best Free and Open-Source Identity Management Tools . Especially Shibboleth Consortium and Gluu appear interesting to me. But this topic is beyond my knowledge.
@qsmd : I would be interested in your opinion on this. Is it necessary, are there better/other solutions then this kind of account-management?
I’m pretty sure OpenID does the job. Here is the wiki and here is the ‘connect scopes’-documentation. This is great. Post-Post-script: OpenID is free and decentral, but seems to be not opensource. … We should take a closer look.
I discovered that @qsmd already found some technologies: Technologien, die zu uns passen - #4 by qsmd