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.
short version
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
context
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
self-determined terms of use (text series). “A big pot is needed. Do you have one and would share it?”. If the user agrees, then the pot is in his/her “own means”-library, and the user can set the term of use, manage reservations, etc. pp.
But if we now develop a second app, next to the issmit.app, the same user probably does not want to do the process again. Imagine he/she did the effort to descripe,categorize, make images and set terms of use of 30 different items and the he/she uses a connected app for a different purpose, he/she is asked to do everything again. And what if the terms of use are for example on the one app different from the other? This could be a huge problem, but all in all, the person surly does not want to do the same process on the second app. And he/she won’t even think about doing it for a third app. Of course we need an external means-database, which synchronizes the databases of these apps.
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.
problem
At this point, we have three different apps: The Issmit-App, the unknown second GCS-App and the external GCS-specific means database with or without an user-interface. And all these apps synchronize data with each other. This means: The user adds the pot in the Issmit.app, it gets synchronized to the gcs-specific means-database and from there it gets syncronized with the unknown second gcs-app. And if the terms of use are edited in this second unknown app, this editing gets synced with the external database and the issmit.app as well. Cool.
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?
solution
When the user opens an Issmit-Account, he/she is asked if he/she also wants to open an account on the gcs-specific user-database (this should be handled with a simpel flag as it is used within “I agree with the terms of use”). Then the software opens a bridge between the user data in the issmit-app and the gcs-specific means-database and the data gets synced (I hope it’s that easy).
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).
Further problems
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.
Existing software
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?
Post-script:
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
) solution.