d 2 . 1 d i sru p t i ve t e c h n o l o g i e s i mp l e ... · 5 . 1 , 2 . 5 . 2 , 2 . 6 . 3 , 2...
TRANSCRIPT
CO3: Digital Disruptive Technologies to Co-create, Co-produce and Co-manage Open Public Services along with Citizens
Grant Agreement number: 822615
D2.1
Disruptive Technologies Implementation Report
Keywords: CO3project, H2020, implementation, disruptive technologies, Blockchain, Augmented Reality, Geolocation, SocialNetworking, Opinion, Formation, Gamification, Co-creation, Co-production, Co-management, Open Public Services, Social impact, Best practices
Dissemination Level
PU Public x
PP Restricted to other programme participants (including the Commission Services)
RE Restricted to a group specified by the consortium (including the Commission Services)
CO Confidential, only for members of the consortium (including the Commission Services)
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement number 822615.
CO3 Project D2.1
Authors List
Partner Author(s) Sections
LiquidFeedback (FlexiGuided)
Jan Behrens, Axel Kistner, Andreas Nitsche, Björn Swierczek
1, 2.1, 2.2-2.4, 2.5.1, 2.5.2, 2.6.3, 2.6.5, 2.6.6, 5, 8
UNITO Liliana Ardissono, Gianmarco Izzi 2.5.3, 2.6.1, 2.6.4, 2.6.5
Unit 8 Shubhendu Shekhar, Diego Di Caro, Yashar Mansoori
2.6.1, 2.6.4, 2.6.5, 4.1, 4.2, 4.3 4.4, 4.5, 4.6, 4.7
UNITO Claudio Schifanella, Alberto Guffanti, Guido Boella, Luigi Sanasi
2.5.4, 3
GEOMOTION Pau Yanez 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.2
LINKS Mario Chiesa 7
1
CO3 Project D2.1
Table of Contents
Authors List 1
Table of Contents 2
1. Management Summary 5
2. System architecture and technological integration 6 2.1 Requirements and Integration Framework 6 2.2 Server centric vs. distributed ledger based components 10 2.3 Integration plan 11 2.4 Pilot scenarios, requirements and platform features 14 2.5 CO3 Platform Integration 16
2.5.1 Unified User Management (CO3UUM) 16 2.5.2 Integration framework (CO3UUM extension) 17 2.5.3 OnToMap Logging Service and Data Hub (CO3OTM) 18 2.5.4 Landing page and area viewer 24 2.5.5 Common design reference 24
2.6 Bilateral application integration 24 2.6.1 Augmented Reality ↔ Blockchain 24 2.6.2 Augmented Reality ↔ FirstLife 25 2.6.3 Augmented Reality ↔ LiquidFeedback 25 2.6.4 Blockchain ↔ FirstLife 26 2.6.5 Blockchain ↔ LiquidFeedback 26 2.6.6 FirstLife ↔ LiquidFeedback 26
2.7 Integration of non CO3 components 26 2.8 Status of integration 27
2.8.1 Status of platform integration 27
3. Map-based citizen network 28 3.1 Introduction to FirstLife 28 3.2 The Conceptual Model 28
3.2.1 The User Model 29 3.2.2 The Entity Model 29
3.2.2.1 Connecting Entities 31 3.2.3 Model customization options within CO3 32
3.3 The FirstLife Platform 32 3.3.1 Visualization, filtering and searching for contents 32 3.3.2 Adding contents and basic interaction with FirstLife 33 3.3.3 Taming overcrowded maps via entity clustering 34
3.4 Enabling Coordination, Cooperation and Collaboration 35 3.4.1 Coordination 35
2
CO3 Project D2.1
3.4.2 Cooperation 36 3.4.3 Collaboration 36
3.5 Technical Details 37 3.5.1 FirstLife FrontEnd 37 3.5.2 FirstLife Backend 37 3.5.3 FirstLife Resource Server 37 3.5.4 FirstLife API 37 3.5.5 FirstLife Tile Server 38 3.5.6 Localization 38
4. Exchange System based on Blockchain 39 4.1 Introduction 39 4.2 The Blockchain Network: Hyperledger Besu 39 4.3 Key & User Management 39 4.4 Tokens as enabler of transactions in blockchain exchange systems 40 4.5 Blockchain wallet 41 4.6 Blockchain contracts 41 4.7 Blockchain space economy 41
5. Opinion formation with Interactive Democracy 41 5.1 LiquidFeedback for deliberation and decision making 42
5.1.1 Democratic self-organization 42 5.1.2 Civic participation - LiquidFeedback for citizens 43 5.1.3 LiquidFeedback for the self-organization of communities 43 5.1.4 Isolated use cases versus permanent participation infrastructure 44
5.2 Aspects and objectives of LiquidFeedback 44 5.2.1 Transitive proxies (liquid democracy) 44 5.2.3 Collective moderation 45 5.2.4 Minority protection 45 5.2.5 Noisy minorities 46 5.2.6 Preferential voting 47 5.2.7 Supermajority requirements 49 5.2.8 One individual - one vote 49 5.2.9. Voting weight based on blockchain tokens 49 5.2.10 Trustworthiness 49 5.2.11 Existing gamification aspects in LiquidFeedback 50 5.2.12 Geospatial extension of LiquidFeedback 50
5.3 Structure of LiquidFeedback 51 5.3.1 Organizational units 51 5.3.2 Subject areas 51 5.3.3 Policies 52
5.3.4 Database scheme 52 5.4 Roll-out preparation 53
5.4.1 Technical requirements 53 5.4.2 Localization 53
3
CO3 Project D2.1
5.4.3 Accreditation 54 5.4.4 Scalability 54 5.4.5 Sustainability, dependency and license management 54
6. Augmented Reality interfaces 55 6.1 User Experience (UX) and User Interface (UI) 55
6.1.1 HUD 56 6.1.2 Device camera 56 6.1.3 QR Code reader 56 6.1.4 Wallet 56 6.1.5 First Life 56 6.1.6 LiquidFeedback 57 6.1.7 Dashboard 57
6.2 Localization 58
7. Gamification layer 59 7.1 Gamification goals 59 7.2 Logging of activities for Gamification purposes 59 7.3 Categorization of activities 60 7.4 Roles, levels, thresholds and rules 61 7.5 Visible gamification elements and applications layout 62
8. The System as a whole 64 8.1 Testing 64 8.2 Platform instances 65
8.2.1 Development and training system 65 8.2.2 Prototypes 66 8.2.3 Athens 66 8.2.4 Plaine Commune 66 8.2.5 Torino 66
8.3 Accessibility 67 8.4 Sustainability beyond the scope of the project 67
Annexes 68
4
CO3 Project D2.1
1. Management Summary This document provides a detailed description of the implementation specifications for the involved disruptive technologies. It specifies, in particular, the interaction between the different components based on the agreed integration paradigms which allow a modular development of the components with clear interfaces. In an analysis of the requirements from the proposal and deliverable D1.1, the combination of server centric components and distributed ledger based components was identified as a challenge. Following a developer meeting, the developer teams worked with the pilot sites to collect the missing information on requirements. The chapter “System architecture and technological integration” describes the above requirement elicitation process and the integration plan. The modularized design of the backbones enables the possibility to run it as a distributed system that is perceived/interfaced as one virtual application. To show the flexibility of the design, the chapter exemplifies some bilateral integration and the possibility of including more in the process. The chapters on the individual platform components describe the theoretical background as well as considerations and decisions when it comes to architecture, design, configuration, operational stability and scalability as part of the CO3 platform. These chapters also contain the respective database schemes, dependency specifications and license information to the extend they are already available. The chapter on the system as a whole summarises the system architecture, elaborates on the foreseen platform instances and sustainability beyond the scope of the project.
5
CO3 Project D2.1
2. System architecture and technological integration
2.1 Requirements and Integration Framework
Analysis of requirements from the proposal and D1.1 in regard of relevance for integration This section reports about the analysis of requirements with relevance in regard of the overall integration process, i.e. with relevance for the overall technical structure, including interface interconnections, data transmission, transformation, storage and processing, but also the unified user management and the OnToMap data hub. Requirements without relevance for the integration process as well as requirements which require additional bilateral integration between certain components are expected to be analyzed and documented by the corresponding tasks. The requirements and functional description of the envisioned platform are scattered along with the two parts of annex 1 of the grant agreement:
● Part A of annex 1 which outlines the specific work which has to be carried out and regulates which partner is responsible for the execution of development work.
● Part B of annex 1 which describes a vision of what the platform users should be able to do by describing features and providing user stories in the context of the commons.
Most implementation relevant requirements in annex 1 have been found in the following sections:
● the objectives of CO3 (in part A) ● the objectives of WP2 (in part A) ● the task descriptions of WP2 (in part A) ● section B1.1.3 (in part B)
Additionally, the report D1.1 is available and provides further relevant input for the integration. Even while no coherent description of the overall functionality is given in a single place yet, the pieces have been connected to a conclusive picture which is described in the following sections.
Evaluation of risks and benefits for 5 disruptive technologies CO3 is about the evaluation of risks and benefits of 5 disruptive technologies: 1
● Distributed Ledger Technology represented by a Blockchain based general exchange
system where goods and skills are shared. ● Map-based Citizen Networks represented by the FirstLife local civic social network with an
interactive map: it will allow crowdmapping of information by citizens that can coordinate with each other and the PA in the management of urban commons.
1 GA annex 1, part A, section 1.3.3, page 12, WP2 objectives
6
CO3 Project D2.1
● Interactive Democracy represented by the LiquidFeedback deliberation and decision making platform which allows democratic self-organization of large scale groups with equal rights.
● Augmented Reality demonstrated by a flexible Augmented Reality/photosocial user interface.
● Gamification demonstrated by designing gamification widgets for behavioral incentives distribution.
The evaluation of the technologies shall be based on experiments on an online platform. 2
Applying augmented reality to the commons The context of the evaluation is the co-creation, co-production and comanagement of public services by citizens as partners of PAs. This shall be enabled by a concept based on the 3
commons using an urbanistic interpretation of augmented reality. The augmented reality shall 4 5
build a unique shared layer of geolocated virtual objects , like a shared screen. 6 7
Scarceness of virtual space In opposition to virtual reality, which offers an unlimited virtual space not connected with the real space, the augmented reality shall be limited in a way reassembling the limitations of the real space in order to allow building of a common knowledge (in its game-theoretic meaning) and to allow coincidental perception of information from the proximity (in contrast to a filter bubble). 8 9
Physical presence for certain activities The creation of new objects and some types of interaction with existing objects in the CO3 augmented reality shall be limited to people who are actually physically present in the immediate proximity (within a radius of 15m) of the location of the object. 10
Augmented camera view An augmented reality mobile application shall provide an augmented camera view, enriched with data from FirstLife, LiquidFeedback and the blockchain exchange system , all three acting as 11 12
backend for augmented reality. The augmented reality mobile application shall progressively 13
display data and offer features of the different components. 14
2 GA annex 1, part B, section B1.1.3, page 7, challenge 3 3 GA annex 1, part A, section 1.1, page 3, project summary 4 GA annex 1, part B, section B1.1.1, page 5 5 GA annex 1, part B, section B1.1.2, page 7 6 GA annex 1, part A, section 1.1. page 3, project summary 7 GA annex 1, part B, section B1.3.a.2, page 16 8 GA annex 1, part B, section B1.3.a.2, page 16 9 GA annex 1, part B, section B1.4.1.a, page 33 10 GA, annex 1, part B, section B1.4.1.c, page 34 11 GA, annex 1, part A, section 1.3.3, page 13, description of task 2.5 12 GA, annex 1, part B, section B1.3.b.1, page 32, WP2 13 GA, annex 1, part B, section B1.3.a.3, page 19 14 GA, annex 1, part A, section 1.3.3, page 12, WP2 objectives
7
CO3 Project D2.1
Objective vs. sensorial experience The augmentation should not necessarily be provided by a sensorial experience. The focus shall be the objective experience. Consequently, alternatively to the camera view, another view like a photo album or object listing shall present data objects from FirstLife, LiquidFeedback and the blockchain exchange system which are geolocated in close distance to the user. 15
Map view In addition to the augmented reality camera view and the photo album/object listing, a third access path for users is foreseen: an interactive 2D map view based on FirstLife integrating information from other components. 16
Three interfaces on the same data set A similar set of three views on the same data set has been developed in task 1.2 (Enabling Technology:
● a 3D view with the augmented reality mobile application ● a 2D view using a web based map ● a 1D view with objects from the proximity sorted by distance or importance
Notifications FirstLife shall allow to subscribe to places and objects and notify the subscribed users on ongoing activities concerning these objects and places as well as activities of groups the user has joined. 17
Implicitly, this requires that all data relevant to generate these notifications is available for FirstLife, according to the integration paradigms via the OnToMap data hub.
Offline events for certification of identity The platform shall support the verification of user identities by participating in certification events.
18
Integration paradigms The integration shall follow the integration paradigms developed through the WeGovNow! project and is supported by components developed during WeGovNow! , namely: 19
● Unified user management (and integration framework) ● OnToMap data hub
D1.1 mentions additionally the following components which also have been developed during WeGovNow : 20
15 GA, annex 1, part B, section B1.4.1 c), page 34 16 GA, annex 1, part B, section B1.3.a.3 1), page 19 17 GA, annex 1, part B, B1.3.a.5, page 23 18 GA annex 1, part B, section B1.3.a.2, page 19 19 GA, annex 1, part A, section 1.3.3, page 12, WP2 objectives 20 D1.1
8
CO3 Project D2.1
● AreaViewer embeddable map viewer ● InputMap embeddable map input widget
OnToMap The OnToMap software component shall act as central data hub for geolocated data. Every data generating component shall report geolocated data to OnToMap and every visualization component shall obtain unified data from it. More specifically, while textual geolocated data is 21
stored in the hub and can be directly retrieved from applications, these will only send metadata of multimedia content to OnToMap, in order to save bandwidth and memory space.
Unified user management A unified user management component shall provide single-sign-on capabilities to be shared by the camera view, the map view, and the photo album view as well as the blockchain wallet and LiquidFeedback. This component shall also store the user profile data. 22
AreaViewer and InputMap The AreaViewer and the InputMap shall provide embeddable map views for displaying information and entering geographic coordinates for geolocating entities stored in other components. 23
Development strategies To implement the platform, different strategies have been foreseen for different technologies:
● The geolocated social network and interactive democracy is demonstrated by already existing applications, namely FirstLife and LiquidFeedback, which shall be customized for the use in the context of the commons.
● Two other technologies are foreseen to be implemented as new components during WP2 based on existing, mature frameworks and libraries: The blockchain exchange system and the mobile application for augmented reality.
● Gamification shall be an inherent concept during the development of the new components. Gamification elements shall be included in the existing components. 24
Agile development The work in WP2 shall be carried out with the aid of agile development principles . The work shall 25
focus on people and their interaction. This is mainly achieved within the different developer 26
teams and supported by bilateral discussions and negotiations between the teams and multiple
21 GA, annex 1, part A, section 1.3.3, page 13, description of task 2.5 22 GA, annex 1, part B, section B1.3.a.3, page 19 23 D1.1 24 GA annex 1, part A, section 1.3.3 Work package description, description of tasks WP2 25 Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved 14 June 2010. 26 GA annex 1, part B, section B1.3.b.2, page 32
9
CO3 Project D2.1 pre-releases to allow interaction with all people involved in CO3 during the development of each prototype.
2.2 Server centric vs. distributed ledger based components The contrast (“contradiction”) between server centric components (FirstLife, LiquidFeedback, OnToMap and the unified user management) on one hand and the distributed ledger based blockchain exchange system on the other hand has been identified as probably the most conspicuous contradiction in regard of the technical implementation of CO3: The blockchain exchange system is decentralized by definition but it shall be integrated with server centric components. As it is not obvious at first glance, it should be mentioned that the foreseen approach does not only fulfill the requirements of the proposal but also comes with several advantages:
● The well thought features of the server centric components can be integrated in the newly developed components without the need to completely reimplement these components based on distributed ledger technology which would have been out of scope of this engagement and evaluation project.
● Building a connection between a distributed ledger based exchange system and server centric components shows a transition path from traditional server centric systems to distributed systems allowing to coexist until the features of server centric components have been made available based on distributed ledger technology. It has already been identified that this will support the integration of existing tools at pilot sites during the course of CO3. 27
● Last but not least, the approach allows to combine the new components with every existing component following the same integration paradigms. The growing H2020/WeGovNow/CO3-ecosystem has already been discussed in the proposal and can 28
be enriched by third party applications, such as the IRI tools. 29
Practically, four types of connectors have been identified to be developed to enable the connection between both worlds:
● So called oracles, providing a consensus on events which happened outside the blockchain as input for smart contracts in the blockchain
● Blockchain-OnToMap-connector, providing geolocated data from the blockchain to the OnToMap data hub
● Blockchain-LiquidFeedback-connector, providing voting relevant data from the blockchain to LiquidFeedback
● Connecting a blockchain account with a unified user management account Otherwise, this approach does not limit the development of the blockchain exchange system in accordance with the inherent principles of distributed ledger technology. Even the data exchange between the blockchain exchange system and the augmented reality application could take place
27 D1.1 28 GA, annex 1, part A, section 1.3.3, page 12, WP2 objectives 29 D1.1
10
CO3 Project D2.1 directly, as long as the data with relevance for the 2D map view and the notifications are (also) provided to OnToMap.
2.3 Integration plan The integration plan for the CO3 development work aims at creating a foundation for the CO3 platform envisioned in the Grant Agreement. While the concept of the CO3 platform describes very high level concepts on human interaction, the integration plan focuses on requirements and unleashes the potential of the integration between the different components of CO3 on the technical level. The focus here is not at the underlying economic ideas but merely to enable them along with a large range of possible use cases while also striving for compliance with EU directive 2016/2102 on accessibility of the websites and mobile applications of all public sector bodies. It has to be noted that a full compliance is impossible due to properties of Augmented Reality and, to a lesser extent, also maps. While both provide unique ways of accessing information and support spatial cognition, they come with inherent barriers to people with certain disabilities.
Work done by task 1.2 - Enabling Technology During task 1.2, technical challenges regarding the way to present information has been identified. As work thesis, it has been assumed that the real world shall be augmented (enriched, expanded, made greater in size or value) with virtual commons related objects located in the user’s proximity (neighborhood, objects with short distance) while striving for convergence (fusion, unification) of real and virtual objects. A technological key is geolocating objects in a virtual space which is mapped to the real space. Geolocations can come in two flavors:
● 2D geolocations, consisting of a longitude and a latitude ● 3D geolocation having an additional height and information on their rotation in space in
case of complex objects To achieve augmentation, at least two principles need to be followed:
● Users shall be able to place virtual commons related objects on geolocations in the proximity of the user’s current location.
● Users shall be able to interact with these objects whenever they enter the proximity of the object.
These principles can be implemented with the following mechanisms:
● Objects created in FirstLife, LiquidFeedback and the Blockchain Exchange System shall be linked to a geolocation during creation.
● Objects with a geolocation near the user’s geolocation shall be presented for interaction.
11
CO3 Project D2.1 The proximity of a user are the objects which are in short distance. Therefore, the user's surroundings consist of all objects created in FirstLife, LiquidFeedback, and the Blockchain Exchange System, which are in a determined radius to the current geolocation of the user. Convergence between the virtual and the real space can be achieved in different ways, e.g.:
● Text view list with objects from the user’s proximity ○ Push notifications of list when user enters new area ○ Nearest first, or relevance weighted proximity search
● Map view of the user’s proximity with objects positioned at their geolocations ○ different zoom levels with different level of detail
● AR view of proximity of the user with embedded objects placed at their geolocations ○ showing the immediately visible proximity (camera’s viewport)
Exhibit: Different representations with different trade-offs. Source: FlexiGuided GmbH
WP2 Meeting in Berlin On the occasion of the start of WP2 in July 2019, a WP2 meeting in Berlin was held. With task 2.1 (Integration) being the only active task by that time, the meeting had two main objectives: Discussing the integration and providing a preview on the “new” technologies, i.e. the technologies not already represented by mature applications, namely Augmented Reality and Blockchain. In addition, the participants of the WP2 meeting agreed with OLA, the task leader of task 1.1, to analyze the use cases identified by the pilot sites and to translate them into technical requirements for the tasks within WP2. It has been agreed to identify commonalities and to look at two dimensions, the user experience and the business logic/functional requirements.
12
CO3 Project D2.1 The Integration Framework allows to integrate features of the existing server centric components in the blockchain exchange system. This also opens a transition path from server centric to distributed approach while maintaining compatibility with existing Horizon 2020/WeGovNow components. It also allows the integration of existing applications (e.g. IRI tools).
What we already have ● FirstLife (map based social network) ● LiquidFeedback (opinion formation and decision making) ● OnToMap (event logger and data hub) ● Unified user management ● AreaViewer and InputMap (map view and input) ● LandingPage (introductory entry point) ● Further platform services for integration ● Material design as design reference
Exhibit: What we already have. Source: FlexiGuided GmbH
What we need ● Blockchain Exchange System (Unit8) ● 3D Augmented Reality App (Geomotion) ● Gamification Layer (LINKS) ● Photo gallery / List view ● Push notification (FirstLife) ● Extensions / adjustments of existing components
13
CO3 Project D2.1
Exhibit: What we need. Source: FlexiGuided GmbH
2.4 Pilot scenarios, requirements and platform features Following the WP2 meeting in Berlin, WP2 and WP3 undertook a common endeavor to match the proposal and current pilot scenarios with already existing and foreseen features and to identify desired features. The result is a unified feature list which contains
● A feature name and description, ● Which user group can use a given feature, ● How the access to a feature is managed, ● By which means and where a feature can be used,
(App everywhere, App in proximity, Desktop), ● Which partner provides the feature, i.e. which developer team is responsible, ● Origin of request for a feature (proposal, pilot scenarios), ● The implementation status, ● Comments from the developer teams.
The feature list serves both the communication with the pilot sites as well as the internal coordination of WP2 and allows to
● Identify gaps, i.e. missing features, ● Identify dependencies and plan the interaction between the features, ● Agree on responsibilities and track the progress of implementation.
The implementation status indicates the (prospects of) availability of a given feature:
● Suggested feature has been suggested but needs further discussion
14
CO3 Project D2.1
● Assessment complex and/or vague idea which needs to be assessed, conceptualised and split into basic functions assigned to specific developer teams
● Discussion feature is being discussed by the affected partners
● Rejected feature will not be realised or replaced by an alternative
● Split feature has been split into sub features/parts/modules
● Accepted feature is sufficiently specified, accepted by the responsible partners and likely to be realised
● In progress implementation ongoing
● Ready for use feature available in principle, minor adjustments or configuration may be necessary
The developer teams have continuously discussed the feature list and updated the implementation status assessment. The feature list is still subject to ongoing updates. A version showing the status as of December 30
15, 2019 is attached to this deliverable. The feature list will be reviewed by the developer teams and locked in a web conference in January 2020. The first prototype of the CO3 platform (D2.2) is due end of June 2020. This prototype already needs to be production ready and will be rolled out to the pilot sites from 01.07.2020. In order to involve everyone in CO3 in the development process as early as possible and gather feedback in every stage of the development and to identify problems and risks as early as possible during development and implement countermeasures, the developer teams agreed on three internal alpha prototypes and three release candidates between February and June 2020. The Alpha versions shall demonstrate the progress of development without claiming to be useful for productive usage. This still allows all CO3 partners to experience the development progress and comment on it, to monitor the progress, and identify challenges and risks. Starting from Release Candidate 1, we will aim at providing a version of the platform which is already usable and ready for production. Together with the two subsequent Release Candidates, this gives us about a month for intensive testing and improvement prior to the completion of Prototype 1.
30 Annex: Unified CO3 Platform Feature List as of 15.12.2019
15
CO3 Project D2.1
2.5 CO3 Platform Integration
2.5.1 Unified User Management (CO3UUM) Users can use the platform without registration/logging in until the moment when an action shall be performed which (according to the application used) requires a login. At this moment the current application triggers the login screen and returns the user to the activity he/she was going to perform. The Unified User Management (CO3UUM) provides a Single-Sign-On. Logged in users are recognised by all applications which also allows a CO3 application to trigger actions in other applications.
Single sign-on for distributed components and heterogeneous infrastructure We will use a technology based on the OAuth 2.0 standard to allow user identification on the internet: The CO3 Unified User Management (CO3UUM) provided by LiquidFeedback acts as an identity server, and, given a proper accreditation process, other CO3 and third-party software may use the CO3UUM service to verify identities when collecting quantified user input (single-sign-on with identity verification). This allows organizations or political administrations to build an extensible ecosystem of internet applications that are invulnerable to the sockpuppet problem where users create a number of (fake) internet identities to unfairly increase the impact of their postings or votes. The implementation supports role accounts for stakeholders, e.g. NGOs. CO3 partner LiquidFeedback developed the software providing the CO3UUM service in the course of WeGovNow, a previous H2020 project. The development was based on the following considerations: Pre-existing third party implementations use a form of client registration, which is only suitable for a service-centered approach where the software provides only a single service (e.g. Facebook, Google, Twitter, etc). When considering an open source ecosystem, more than one installation of a particular technological solution is to be expected. It is therefore not sufficient to register a client at a single service provider if this client shall be usable for any authorization server using the same (open source) software. One possible solution would be the creation of a central (i.e. world-wide) client registry. Such a central client registry, however, could be a single point of failure and would empower a central authority (e.g. the Public Software Group) to control usage of the protocol. We consider this approach contrary to the concept of open source and open data. Therefore, we implemented a dynamic client registration protocol that keeps implementational complexity at a minimum while providing good security properties. LiquidFeedback's (general purpose) OAuth 2.0 server implementation can also be used for all other purposes that OAuth 2.0 may be used for. Further improvements have been made to extend the basic OAuth 2.0 workflow. For example, RFC 6749 suggests refresh token rotation to provide better security properties but does not specify how old refresh tokens are invalidated. Always revoking the old refresh token after transmission of a new refresh token can have a bad effect on system stability, considering that transmissions might not be processed properly by the receiver. Furthermore, multiple backends of a client could simultaneously access the OAuth 2.0 token endpoint. Such legit accesses by two legit backends of the same client would need to be distinguished from accesses by a legit client and a malicious third party who obtained a copy of a refresh token. In the work report, we explain the mechanisms employed by LiquidFeedback to mitigate the risk of refresh token abuse while solving the problems of race conditions during
16
CO3 Project D2.1 refresh token rotation. Another improvement, for example, is to allow downgrading access token scopes to allow meta-API providers.
Trusted CO3 applications and dynamic client registration To create a trustworthy relationship between applications using CO3UUM and the CO3UUM component, we will use X.509 certificates. Any official CO3 application (client) is required to provide a valid X.509 certificate with each request made to the CO3UUM service. On the other hand, even a complete new (non-registered, third-party) application can easily make use of the CO3 infrastructure. The application can request certain scopes from CO3UUM (which can be granted or declined by the user) and use the appropriate services of all other CO3 applications. Using the application and service discovery (see integration framework), this is also possible vice versa.
Scopes vs. privileges The scope does NOT grant a privilege to a user, it just means an application can trigger an action within the scope *if* the user is authorized to perform the action. Example voting: an application needs the scope "vote" to cast a vote on behalf of the user but casting a vote will only work if the user has the necessary voting privileges. The business logic remains with the CO3 applications. This can be described as a matrix of scopes and user privileges or (alternatively) as a logical AND conjunction. Scopes control that an application does not misuse user privileges: while the trusted CO3 applications can request certain scopes without user interaction, a non-trusted third party application/client would trigger a request for confirmation by the user "Do you want to allow application X to cast votes on your behalf? [yes, one time / yes, permanently]" (compare to permissions for third party Twitter/Facebook clients and Android permissions). The CO3UUM service with the appropriate extensions automatically empowers all organizations or political administrations which use a CO3 platform to provide identity services to third-party applications, even those applications unknown to the organization at the deployment time.
2.5.2 Integration framework (CO3UUM extension) The integration framework is an extension of CO3UUM and includes a style endpoint to retrieve style information, a navigation endpoint to incorporate a common navigation bar into the user interfaces, and a service discovery endpoint to retrieve a list of other applications within the system and their capabilities/protocols.
Style service A dedicated style endpoint of the CO3UUM service provides basic colour definitions for a primary and an accent colour as 24-bit RGB triplet to be able to customize the unified visual look of all WeGovNow applications for a particular installation by central configuration. Additional colours can be derived from these two base colours. If the CO3UUM server gets configured with colours from the Material Design colour palette, the corresponding Material Design colour name of the primary and the accent colour is also provided.
17
CO3 Project D2.1
Navigation bar In order to integrate all CO3 applications in such a way that they look and feel like a single application, all CO3 applications share a common WeGovNow navigation bar (where appropriate). The navigation endpoint of the CO3UUM server returns this navigation bar to be included by each CO3 application. This way, modifications to the navigation bar can be made at a central place without the need to change every single application. Either a login button or the user name with a link to a user page (where logout is possible) is included in the navigation bar, depending on whether an access token is provided when calling the endpoint.
Application and service discovery The application and service discovery endpoint of the CO3UUM service returns a list of all system applications and, if an access token is provided, a list of all registered dynamic clients for the corresponding user. This facilitates communication between applications that have not been known at the time of development.
2.5.3 OnToMap Logging Service and Data Hub (CO3OTM) The OnToMap Logging service and Data Hub (CO3OTM) has the following roles in the CO3
platform (the API of the Logger can be found at https://dev.co3.ontomap.eu/):
1. semantic data interoperability among platform applications
2. cross-application logging of user actions
3. data hub for the CO3 applications
In detail:
Semantic data interoperability among platform applications. CO3OTM defines a unified
information representation format that represents an interlingua specification of geographic
information and of user actions. Specifically it provides both syntactic interoperability among
applications, based on the use of JSON (www.json.org) as a standard for the exchange of
information, and semantic data interoperability:
● Unified, semantic representation of the types of data used by the applications of the platform.
As applications can use diverse conceptual models (and different lexical formats) to represent
geographical information and the various types of information they manage, heterogeneous
data descriptions have to be reconciled in order to support data sharing. CO3OTM enables
applications to share information collected about geographical objects, initiatives, activities,
and so forth, so each platform application can successfully interpret the data collected by the
other applications, regardless of the terminology they adopt. The OnToMap Logger addresses
this issue by exploiting a semantic representation of information provided by OnToMap
Ontology, that is used as an interlingua among CO3 applications. The ontology formally
represents the concepts in which the data shared among applications can be classified.
Mappings between the concepts used by the CO3 application and the OnToMap Ontology have
to be defined and published to the OnToMap Logging Service at application integration time,
otherwise the application will not be able to interact with the logger. These mappings are
expressed as concept translation rules that specify, for each application concept, the name of
the corresponding OTM Ontology concept, and similar for the attributes of the concept. The
18
CO3 Project D2.1
OnToMap Ontology is defined in the OWL language (www.w3.org/OWL/) and its latest version
is available at https://dev.co3.ontomap.eu/ontology/. ● Unified representation of user action types, i.e., of the types of actions that are carried out by
interacting with the other CO3 applications and have to be logged in order to maintain a
unified history of the events occurring within an instance of the platform. This is an important
aspect to define a clear protocol for the interaction between CO3 applications and CO3OTM.
CO3OTM defines a customizable set of types of actions that can be tracked at the level of the
whole platform (e.g., object creation, object modification, etc.) in order to compose a
centralized log of user actions to be shared among applications. The types of user actions that
can be logged are defined in collaboration with the developers of the CO3 applications and
they are defined in the CO3 OnToMap Logging Service which specifies: which kinds of events
can be logged and which format has to be used to push events to the Logger, as well as the
formats of the events that the logger returns to applications. For the definition of the structure
of action types, and of the types of actions that can be pushed to the Logger, we build on the
WeGovNow experience, in which a certain number of action types were defined; however, we
are extending the format of the actions, and the types of action that can be logged in order to
answer the requirements of the CO3 applications (e.g., to specify the ACAs in which actions are
tracked and new types of actions, such as those related to blockchain management and
gamification).
Centralized logging of user activities. CO3OTM is a cross-application, centralized collector of the
history of actions performed by CO3 users by interacting with the CO3 applications, and that the
applications decide to disclose in the platform. The goal is that of achieving a unified perspective
on shared user behavior, so that each application can interact with the user by possibly taking
her/his previous actions into account.
The logger offers APIs to:
● publish the application concept mappings needed for data interoperability
● push events that describe user actions in order to share them within an instance the
platform: either individual events, or lists of events in batch loading, can be pushed in a
single interaction with the logger
● retrieve shared data concerning user actions and/or geographic information items
previously shared through the logger within an instance of the platform
CO3OTM integrates data shared by heterogeneous applications; it collects data about both user
actions and geographic objects that the actions are about. The goal of the logger is that of
enabling each application within an instance of the CO3 platform to log user actions it has tracked,
or to retrieve, in the interlingua format, user actions tracked by other applications of the platform.
In this way, each application can perform its own business logic by taking contextual information
deriving from other applications into account. The logging service is organized as follows: within
the platform, applications push their log data to CO3OTM, which merges the information
managing a unified history of user activities. In order to effectively support information retrieval,
centralised logging has to be coupled with data interoperability support. In fact, as applications
can adopt different terminologies, the user activities they log might seem to refer to different
types of information even when it is not the case. For instance, two applications might refer to the
same concept (e.g., Kindergarten) by using different terminologies (e.g., kindergarten vs. child
care). In order to understand that both events refer to the same type of geographic object, the
19
CO3 Project D2.1 Logger employs the semantic representation defined in the OnToMap Ontology and the mappings
between ontologies defined at applications setup time.
The centralized logging scenario supported by the OnToMap Logging Service is depicted in the
following picture: two CO3 applications push action logs to CO3OTM using their own terminology.
When CO3OTM receives any logged action, it translates the parameters of the action, i.e., the
objects involved in it, to the unified representation format defined in the OnToMap Ontology and
it stores the translated event. In this way, the event, and the information it carries (e.g., the data
about a geographical object that has just been created) will be available to any other CO3
application in the interlingua format. This means that CO3 applications can be integrated into the
platform by means of the interlingua, and they do not need to understand each other’s
terminology in order to collaborate.
Exhibit: centralized logging of user activities within the CO3 platform and retrieval of information in interlingua format.
We depict a sample interaction flow between two CO3 applications and logger in order to provide
an intuition of the cross-platform logging provided by CO3OTM:
20
CO3 Project D2.1
Exhibit: sample interaction between CO3 applications and CO3OTM.
The CO3 applications (App1 and App2) push tracked user activities to CO3OTM at different times
(t1, …, t3). Each time, the logger translates the activities to the interlingua format and it stores
them into the log. When an application (e.g., App2 at time t4) queries the logger to retrieve a list
of user actions, it receives the list in the interlingua format. In more detail, given the mappings
between the terminology used by an application and the OnToMap Ontology, the tracked actions
are translated to the interlingua format by the logger. The following figure shows a sample
translation performed by CO3OTM:
Exhibit: translation of an action from the source terminology to the interlingua format.
21
CO3 Project D2.1 CO3OTM provides APIs to retrieve log information in a flexible way; for instance, it may be invoked
by specifying the following filters, and other ones that we do not list for shortness:
● actor: returns the logged actions that have been performed by the specified user
● start time, end time: returns the logged actions that have been performed in the specified
time interval
● application: returns the logged actions that have been pushed to CO3OTM by the specified
application
● activity type: returns the logged actions belonging to the specified type
● bounding box: returns the logged actions concerning objects located in the specified
geographical area
● concept: returns the logged actions concerning instances of the specified concept
● external url: returns the actions concerning the specified object as a URI
● reference_concept: returns the logged events which contain activity_objects belonging to
the specified concept (OnToMap terminology).
● ...
It is worth noting that, while the management of information items is based on a single protocol,
we plan to handle multimedia content in a rather different way with respect to the other types of
information, for scalability purposes. Specifically, in order to limit the transfer of possibly large
files across the Internet, multimedia items will be stored by the applications that generate them
and only their metadata will be sent to CO3OTM for centralized storage in the platform. In this
way, the logger will be used as a data hub but the applications that need specific multimedia items
will identify them through the logger and download them from the source applications. As for all
the other types of geographic information, external URLs will be provided by applications, and
used by the logger, in order to guarantee that those information items are identified across
platform components in a non-ambiguous way. Thus, the applications requiring multimedia
content will download metadata from the logger and exploit the external URL included in the
metadata to require the multimedia content from its own source application. Notice that the
centralized storing of metadata supports its inspection before deciding whether it is relevant to
download multimedia content from the source application or not.
Data hub for the CO3 applications. The logging service provided by CO3OTM has been developed
in order to provide full information about the user activities tracked by the CO3 applications. This
means, e.g., that if a user creates a geographical object, the Logger stores information about the
object itself, and is able to return this type of information to applications, when invoked.
Specifically, as the Logger translates information to the interlingua, it returns data in a format that
can be understood by any application within the platform. This function makes the Logger a data
hub that can be invoked to retrieve any types of information items collected by the CO3
applications and shared in the platform; e.g., geographical objects, initiatives, wallets, etc..
Data items are returned as JSON FeatureCollections, i.e., as lists of objects of type Feature, where
the Feature represents both geographic and non-geographic items. For instance, consider the
following example, which includes two geographic objects:
{
"type": "FeatureCollection",
"features": [
22
CO3 Project D2.1 {
"type": "Feature",
"geometry": {"type": "Point", "coordinates": [45.5, 7]},
"id": "http://ontomap.eu/ontology/Park/1",
"application": "ontomap.eu",
"provenance": "http://ontomap.eu/ontology/Provenance/1",
"properties": {
"external_url": "https://ontomap.eu/api/v1/instances/Park/1",
"hasType": "Park",
"label": "Park 1"
}
},
{
"type": "Feature",
"geometry": {"type": "Point", "coordinates": [45, 7.5]},
"id": "https://app1.co3.eu/Parks/5",
"application": "app1.co3.eu",
"properties": {
"external_url": "https://app1.co3.eu/Parks/5",
"hasType": "Park",
"label": "Park 5"
}
}]
}
Similar to the APIs for retrieving filtered logs, CO3OTM provides flexible APIs to retrieve shared
data by applying different types of filters, such as by source application, by concept, by bounding
box or by distance from a point, by time points and intervals (from, to). Notice that, as information
items can be modified at different time points, the APIs return the latest version of the items in
order to guarantee that the item descriptions delivered to the CO3 applications are up to date.
As a final remark, we expect to share within the platform those types of information that can be
considered as “public within a platform instance”, i.e., that each application will send to the logger
events corresponding to user activities that can be analyzed by any other platform application.
However, past experience in WeGovNow project has revealed that there are scenarios in which
some information items are created as public and could become private later on, or vice-versa;
e.g., some projects could change state in this sense. Moreover, some applications might need to
log events for their own sake. In order to comply with these possible situations, and to enable
applications to receive complete logs, including their own private events, the logger supports data
visibility management: the application that creates a data item can change its visibility status by
interacting with the logger and, consequently, CO3OTM will only return to CO3 applications items
that are not private, or that have been created by the applications requiring the data.
23
CO3 Project D2.1
2.5.4 Landing page and area viewer
The Landing page is part of the web view, one visualisation of the proximity. It allows to access CO3 with a web browser including mobile browsers. It also allows being more inclusive for users with disabilities. The LandingPage has two main components:
● AreaViewer, a map-based view integrating information about the activities in the current instance of WeGovNow
● UserArea, a menu to collect direct links to user’s last activities in the different CO3 components
The LandingPage, developed in Angular >2.x, is fully integrated in the CO3 platform and it is highly customizable: it will include the styling personalisations and information requested for each CO3 pilot sites. In details, the AreaViewer is a web map based module providing a view of CO3 aggregated data based on OnToMap data hub. It works in combination with the InputMap component, exploiting the explicit relations between application data of CO3 components and OnToMap entities. The purposes of the AreaViewer are enhancing the overall look and feel of CO3 platform and providing a coherent visualisation of the status of Co3 instances across components. AreaViewer presents information from the overall CO3 platform extracted from users’ activities via the OnToMap logger interface. The AreaViewer is a component of the LandingPage that can be included in any CO3 component through iFrame (embed) and be controlled via url. AreaViewer has two main status: “explore” and “focus”. In explore status it is possible to pan and zoom the map, changing the view port, and to filter entities according to the source components. Clicking will cause to switch to focus status. The focus will highlight the clicked area, listing only the entities within it, and hiding all points of interest (POIs) not related to the specific area. In focus state, a click inside the focus area will cause to focus deeply on a new area, a click outside the focus area will cause to go back to explore mode, restoring the previous viewport. A click on one of the listed entities present in the focus area, will cause a redirection to the entity details within the belonging component by using the deep-linking bilateral integration method. AreaViewer is based on Leafletjs technologies, a famous open source JavaScript library for web maps. It is developed in JavaScript ECMA6 and released under MIT license.
2.5.5 Common design reference The common design reference for creating new components is the material design concept as published by Google.
2.6 Bilateral application integration Further bilateral application integration can build on the platform integration using the Unified User Management, the Integration Framework and the OnToMap logger service.
2.6.1 Augmented Reality ↔ Blockchain Since the Blockchain exchange system is an integral component of the app, it must provide stringent linkages to the augmented reality interface. The wallet will be embedded within the app and allow for a multitude of features and actions to be sent to the AR app such as exchanging
24
CO3 Project D2.1 tokens between users, and collecting virtual vouchers and coupons available in the AR view. This is done through two paths: APIs provided by the blockchain exchange system and deep linking features.
2.6.2 Augmented Reality ↔ FirstLife GEOMOTION will discuss possible deep integration features with FirstLife based on the FirstLife API specification which is not yet available.
2.6.3 Augmented Reality ↔ LiquidFeedback The Augmented Reality Layer can allow to interact with LiquidFeedback. The big challenge will be to find a proper concept for integration. LiquidFeedback comes with a large variety of crucial features which all need to be accessible by users to enable the LiquidFeedback proposition development and decision making process. It is out of scope for this project to create a fully-featured integration (e.g. units, subject areas, initiatives, suggestions, opinions, draft editor, preferential voting, …) which would allow to waive the existing LiquidFeedback web browser based frontend for the CO3 platform. Therefore, it would be purposeful to focus on a specific set of features for direct integration into the Augmented Reality application and allow users to switch to LiquidFeedback for any other action. In this context, we also have to think about sustainability beyond this consortium.
Display of LiquidFeedback initiatives as a marker in the Augmented Reality application LiquidFeedback already allows linking an initiative with geolocation. Basic information regarding each initiative can already be streamed to the OnToMap logger. The AR software could fetch this data from the OnToMap logger (together with data from other CO3 applications) and display a marker for each geolocated LiquidFeedback initiative (along with markers and other objects from other CO3 applications).
Provide basic information related to LiquidFeedback initiative markers Along with the marker, the Augmented reality application could provide the following information from the OnToMap data stream:
● Number and name of the initiative ● Information regarding state and the remaining time ● Competing initiatives in the same issue
Provide further information related to LiquidFeedback initiative markers Additionally, it would be possible that the Augmented Reality application fetches more information regarding an initiative from LiquidFeedback which are not part of the OnToMap data stream by directly polling the LiquidFeedback API, which could be extended for that purpose, e.g.:
● Supporter counts ● Initiative draft texts ● Suggestion made for an initiative
25
CO3 Project D2.1
● Opinions given on suggestions ● Information on authors or supporters
LiquidFeedback initiative markers linking to LiquidFeedback In the most basic case, these markers could act as a link to the corresponding LiquidFeedback initiative to be displayed in a web browser.
Support of a LiquidFeedback initiative from within the Augmented Reality application Further even basic interaction (e.g. support of initiatives) would in any case require to display initiative drafts texts (which can be long for complex issues) in the Augmented Reality application. These texts need to be visible before any meaningful action is possible. Provided that this can be solved, it would be possible to directly allow to add or remove support to/from an initiative from within the Augmented Reality application. The necessary interface could be added to the LiquidFeedback API and called by the Augmented Reality application whenever support is added or removed.
2.6.4 Blockchain ↔ FirstLife Any organization or place registered on FirstLife will also have access to the blockchain exchange system. The organization at the time of registration will be provided with a wallet that can be used to create/sign transactions on the blockchain.
2.6.5 Blockchain ↔ LiquidFeedback
Voting weight based on blockchain tokens: The blockchain exchange system will enable weighted voting on LiquidFeedback using the tokens present on CO3 blockchain. The number of tokens owned by the user under his/her registered wallet address will be calculated by the blockchain system. The tokens owned by the user will define the weight of his/her vote in a given LiquidFeedback initiative. LiquidFeedback will be used for creating/managing initiatives. At the end of the initiative, LiquidFeedback will use blockchain service to calculate the tokens owned by the users involved in the initiative and assign a weight to each user’s vote. The necessary interface/APIs will be added to the blockchain exchange system. LiquidFeedback will need to consume the data provided by the interface to perform the necessary weight calculation.
2.6.6 FirstLife ↔ LiquidFeedback A bilateral integration between LiquidFeedback and FirstLife has already been developed during the previous H2020 project. Additional deep integration features between FirstLife and LiquidFeedback will be discussed during the course of WP2.
2.7 Integration of non CO3 components The CO3 integration paradigms allow the integration of existing and future eGovernment and other third party applications. The technical integration has to be accomplished by the third party component owner. Additional bilateral integration between CO3 components and third party applications is generally possible but needs to be assessed in terms of available resources,
26
CO3 Project D2.1 necessary effort and potential value. The pilot sites decide about the inclusion of available third party applications into their CO3 platform instances. Deliverable D1.1 names three non CO3 applications: hypothesis.is by IRI, RenKan by IRI, ePlanete. Following the WP2 Meeting in Berlin, IRI further analysed the possible integration of these applications and concluded that ePlanet doesn’t need to be integrated because it will be used by moderators during workshops rather than directly by users of the platform. However, the integration of hypothes.is, RenKan and Minecraft (not yet mentioned in D1.1) shall be further pursued.
2.8 Status of integration LiquidFeedback provides the documentation of the unified user management and integration framework. UNITO provides the documentation of the OnToMap logger. Additional bilateral integration will rely on the aforementioned basic integration. FirstLife and LiquidFeedback have already accomplished the basic integration and have also implemented some additional bilateral integration. When creating an initiative in LiquidFeedback, complex FirstLife objects can be referenced (rather than just a geographic position). FirstLife can display and link to the content in LiquidFeedback and vice versa.
2.8.1 Status of platform integration
Available documents ● Manual for the CO3 Unified User Management and Integration Framework 31
● Document for OnToMap describing the action types that can be logged 32
Availability of integration components and integration status of CO3 applications
Augmented Reality App
Blockchain Exchange
FirstLife LiquidFeedback
CO3UUM foreseen foreseen ✔ ✔
CO3OTM foreseen foreseen ✔ ✔
31 Annex: Integration Manual for the CO3 Unified User Management and Integration Framework 32 Annex: Document for OnToMap describing the action types that can be logged
27
CO3 Project D2.1
3. Map-based citizen network FirstLife, the civic social network developed at the Department of Computer Science of the University of Turin, represents the tool that will be used in the CO3 project to implement the map-based citizen network. FirstLife offers a wide range of customization possibilities and has been successfully demonstrated in a large list of scenarios and projects . 33
3.1 Introduction to FirstLife FirstLife, as other civic technologies, is oriented to be used as a coordination instrument by different stakeholders for sharing information about what has a public relevance at a local and city level for a plurality of people. However, it excludes contents related to the users' personal life, which instead are predominant in the most popular social networks. Moreover, as a crowdsourcing platform, FirstLife allows the collection of information from users, integrating it with heterogeneous data sources (open data, sensors inputs, etc.). The latter can contribute to build a richer informative environment, enabling the discovery of new insights about the city. FirstLife as a service is supporting and has supported multiple projects. In particular, FirstLife provides a generalist platform (the civic social network) and multiple branch projects. The generalist platform is meant to make available the full use of FirstLife functionalities and sustain at city level all the public activities involving institutions, organized citizens, companies, etc. This reduces the aforementioned fragmentation limit due to the use of a multiplicity of platforms. FirstLife can also be customized for specific purposes or goals through the development of branch projects which may select a subset of functionalities without creating different applications. The version of FirstLife currently in development is the result of a four-year work, during which heterogeneous groups of users helped to review the platform's baseline models and features. This has fostered the implementation of real-life scenarios and operational frameworks into the FirstLife development process in order to effectively support coordination, cooperation and collaboration.
3.2 The Conceptual Model The main objective of FirstLife is to design a collaborative environment for citizens. FirstLife design and development adopted from the very beginning a user-centered design approach through participatory design cycles that continuously feed the platform. The methodology is grounded in the principles of Participatory Action Design Research (PADR). This led to a 34
collaborative digital environment designed on the context's constraints and opportunities and on
33 G. Boella, A. Calafiore, E. Grassi, A. Rapp, L. Sanasi and C. Schifanella, "FirstLife: Combining Social Networking and VGI to Create an Urban Coordination and Collaboration Platform," in IEEE Access, vol. 7, pp. 63230-63246, 2019. doi: 10.1109/ACCESS.2019.2916578 34 M. Bilandzic and J. Venable, “Towards participatory action design research: Adapting action research and design science research methods for urban informatics,” The Journal of Community Informatics, vol. 7, no. 3, Aug. 2011. [Online]. Available: http://ci-journal.org/index.php/ciej/article/view/786
28
CO3 Project D2.1 the stakeholders' goals. The analysis of user requirements, stemming from the continuous engagement of users during the design process, entailed subsequent steps of comparison, evaluation, organization based on abstractions of common elements in different user patterns, then a generalization and systematization of specific functional requirements that should be addressed in the software development: this process involved both the organization of living labs and workshops. The results of this participatory process led to the definition of the FirstLife User and Entity model.
3.2.1 The User Model The user model is based on the fluidity of roles that each user plays in different networks coexisting in the same space, also if at different scales. Starting from empirical evidences and the input collected during the participatory process, and also taking into account the framework of the platform as civic media, three main networks have been identified for each user:
● The professional network including all the work-related relations distributed in a range from the building to the regional level and over.
● The territorial network including the personal and political relations, whereby for political we mean all the relations built with active participation in opinion formation, decision-making processes at local level, management of shared resources, informal leaderships, etc.
● The community networks including membership in local groups or non-profit associations, assuming that each user can be involved in a plurality of communities.
Each network calls for a different capabilities of the user related to the role played when sharing an information. The evidence given on the platform to the user role in real-life allows other users to assess the value and reliability of the information. Within the CO3 project, FirstLife will leverage the functionalities offered by the Unified User Management (CO3UUM) introduced in Section 2: the integration process has been successfully tested in a previous H2020 project.
3.2.2 The Entity Model Urban environments are constituted by complex entities that can be represented in a variety of ways, corresponding to the different views on them that different users may have. Indeed, the fundamental characteristic of urban entities is to have a physical presence, even if ephemeral, and to be a social construction shared within homogeneous groups and among heterogeneous ones. The FirstLife entity model has been inspired by human geography studies: the notions of space and place have been considered as the opposite extremes of a continuum which goes from the ideal geometrical abstraction of space to the experiential world of place. Given this context and the purpose to model social entities on the map, the design phase of FirstLife data model approached the complexity of this domain in different ways. First, it focused on social actions, by structuring entities on the basis of the type of information tracing these actions. Then, it built modular entities, which can be aggregated in different ways to represent different concept types. Finally, if is important to notice that entities can have a temporal dimension to express their possible ephemeral character.
29
CO3 Project D2.1 The current default entity model of the FirstLife platform includes five types of first level entities. Places include facilities hosting public services and utilities, buildings or spaces used for open events and community activities, areas chosen by associations, organizations and companies to implement new territorial projects, points of interest from a socio-cultural perspective, etc. As a civic social network, FirstLife does not focus on private and residential places, but it promotes an active involvement of associations, as well as commercial and productive activities in relation to their contribution for the local development. Events are meant as public events of any type and scale, which includes traditional events such as concerts, exhibitions, festivals, but also micro-events and spontaneous initiatives at the neighborhood scale, that usually do not leave any trace on newspapers and traditional communication channels. By enabling every user to create a new public event, the platform supports bottom-up activities and an active citizenship. Events on the map create a global calendar of the territory. News enable to share notices, announcements, calls and news of local interest, while Extra are stories, novels, projects, testimonials, reports of activities that are linked to the area in which the users live. Finally, Groups operate as virtual units to enable coordination and self-organization of actions in real-life. They enable the sharing of useful information with other groups' members in real time. Each type of first level entity can be described by a set of core and specific properties, providing the user with a homogeneous way to represent real world concepts. The core properties include the name, the description, the user who created it and the last user who updated the entity. Each entity type may also have specific properties, for instance events could have starting and ending dates, duration, an organizer, a list of attendees and a performer. Moreover, an entity has a temporal dimension since it may exist in a specific time interval or not. For example, an artistic installation placed in a square should be included (and visible) in the map only during the time interval of the temporary exhibition to which it belongs. On the other side, a place like a church should always be included in the map, regardless of the considered time interval. For this reason, the FirstLife data model allows to associate to every entity a time interval within which it is valid. All entities can be classified using domain-expert knowledge by using categories, while tags allow the users to create a crowd-based entity description. In detail, the data model introduces a multi-dimensional category system, allowing the definition of multiple categorizations for each entity type in the general platform and in each branch project, overcoming the limits of a single categorization of entities that does not fit with the objectives and the requirements of specific projects. Each category space is also mapped in a common tag space, theoretically enabling the shift of data from a branch project to the main platform. Multiple spaces of categories generate multiple map themes, allowing users to explore the map from different perspectives. In addition, tags allow to describe the key characteristics of entities from a user-centered perspective enabling the creation of a crowdsourced knowledge base. The use of tags overcomes the limits of closed categories and extends at the same time its semantic. First level entities introduced above can be enriched with second order entities such as comments, images, polls and descriptions. They allow users to contribute with information reflecting their specific perspectives. This list is constantly evolving according to the requirements of different project in which FirstLife is used. For example, within the CO3 project, the requirements elicited by the pilot sites will enrich entities with 3D object models and audio files.
30
CO3 Project D2.1
3.2.2.1 Connecting Entities
Starting from single independent entities, FirstLife data model implements a set of relations that can be used to connect entities, enabling the creation of complex urban entities. This mechanism generated the so-called nested entities or sub-entities, configured as a main entity (the first added to the map in chronological order) and a set of entities potentially organized at different depth levels, but with the same set of properties and features of the parent entity. For example, when a user adds an entity to the map - defining its title, categories and description - other users may add sub-entities to the parent one, integrating it with more detailed information, or additional events. The scheme of nested entities resulted to be effective in representing complex urban entities, such as buildings hosting multiple services or big events like festivals constituted by a series of sub-events, relying on the patterns: place-sub-places, event-sub-events, place-events, event-places. The introduction of News and Extra has greatly increased the expressiveness by relying on the relation Place-Extra or Event-News, to support projects oriented to collect community memories or to document an event with its day-by-day updates. This pattern defines what we call the entity's newsfeed, expressing all events, places, news, etc. strictly related to the main entity.
The standard entity model of FirstLife. It defines five first level entities: Places, Events, News,
Extra, and Groups.
Finally, the FirstLife data model allows to group together a subset of entities via PlacesLists. They can be public or with a limited user visibility and will represent independent actions made by different stakeholders towards a shared goal, which can be known from the beginning or not.
31
CO3 Project D2.1
3.2.3 Model customization options within CO3 The conceptual model presented in this section represents the standard data model offered by the FirstLife platform. As demonstrated in many projects in which FirstLife has been used, the platform supports the creation and use of different data models based on the core concepts of entities, categories and relations. Within the CO3 project, this will enable the possibility to fully satisfy the requirements contained in the different use cases defined by all CO3 pilot sites in the WP1 activities. For each scenario, this process will lead to the custom definition of the list of supported entity types, properties, categories and relations, as well as ACL and specific policies. For example, within the CO3 project, FirstLife will be able to represent LiquidFeedback proposals or Crowdfunding initiatives coming from the Blockchain Exchange System: the deep integration with the OnToMap logger will enable automatic data alignment and consistency among different platforms.
3.3 The FirstLife Platform FirstLife actually is offered as a web application accessible via browser both from desktop and 35
mobile devices, and technically speaking it could be integrated in a Webview inside a native mobile app.
3.3.1 Visualization, filtering and searching for contents The main FirstLife interface is composed of a map and a side wall, containing summarized entity details represented by cards. Single entities can be opened by clicking on map markers or on their summarized card on the wall: this will open a detailed view that shows all their properties (such as categorization, description, linked URLs, etc.), their sub-entities, the PlacesLists they are part of and the second level entities related to them, i.e., comments, images, attachments. The web interface has been conceived to offer the user complete control over what they want to visualize on the map, with the possibility to filter contents using different dimensions at the same time:
● Space, by selecting on the map a bounding box and a zoom level; ● Time, by defining the validity of entities in terms of time intervals; ● Content, by selecting
○ The main type of first level entities ○ The category (in progress) ○ Properties ○ Tags defined by the user
Usually, the wall lists all entities created in the current FirstLife instance, ordered by recentness or by a customizable recommendation algorithm, but the platform offers the possibility to switch to a modality in which the map represents a filter where only entities present in the current boundingbox are included in the wall, allowing to focus on the whole city up to a single building depending on what the user is looking for. The search bar allows to search either for an address,
35 http://www.firstlife.org/
32
CO3 Project D2.1 or strings present in the entities, or names, or tags. The detailed card has a link to center the map on something that has been reached in this way.
The FirstLife side wall, map and filter bar
Details of a FirstLife entity
3.3.2 Adding contents and basic interaction with FirstLife Entities can be added to FirstLife via a single step wizard that allow the user to write title, description (containing tags), select the location (by using the map), choose (if applicable) a time span of validity for the entity. The user can also specify (multiple) categories, add additional resources like URLs, documents and images to further characterize the content. After that this step is completed by one user, other users can contribute by adding their opinions in the form of comments (having a text and an optional images), or by adding any other second layer resource. Moreover, users can collaborate by enriching entities with sub-entities, enabling the creation of complex urban entities.
33
CO3 Project D2.1 Users are always aware of the activities involving their interests: indeed, they can receive notifications regarding new activities (added comments or sub-entities) related to the entities they are interested in by following them.
Adding FirstLife entities
3.3.3 Taming overcrowded maps via entity clustering Since the markers on the map can become too crowded, depending of the chosen zoom level, FirstLife will groups entities in a single marker (cluster) when they would be rendered too close to each other. To keep the map expressiveness, clusters show the number of contained entities: the user can easily show and navigate the list of cluster entities by interacting with the cluster marker. Moreover, FirstLife desktop version offers the user to switch to a full screen map visualization, in which entities (and clusters) are represented by simple cards in the bottom side.
FirstLife full map desktop modality
34
CO3 Project D2.1
Preview of a cluster content
3.4 Enabling Coordination, Cooperation and Collaboration FirstLife functionalities aim to enable crucial requirements for the CO3 project such as citizen coordination via the management of task interdependencies and common information spaces. Differently from map services like Wikimapia and Open Street Map, it is explicitly aimed at supporting cities and public institutions in carrying out collective initiatives at a local scale. The main challenges of deploying a tool of this kind is to overcome the system's “cold start” reaching a sufficient amount of information collected and users participating that may push the large-scale adoption of the system. Users will be motivated in using FirstLife within the CO3 environment by the opportunity of using a fully integrated platform offering different kind of services and interaction patterns: they will contribute to the urban life of their city, as well as by the possibilities of finding support to their initiatives. More precisely, the use of FirstLife in real-context scenarios has provided three main dimensions of support: coordination, cooperation and collaboration. While coordination is intended to arrange the preconditions to cooperate and collaborate, the difference between collaboration and cooperation is more subtle. A cooperative work is usually described as a task that is accomplished by dividing it among participants, where “each person is responsible for a portion of the problem solving, while they see collaborative work as the mutual engagement of participants in a coordinated effort to solve the problem together” . 36
3.4.1 Coordination The visibility of entities shared on the map allows users to have an overall view of what is happening in the area of interest. On the one hand, the underlying platform's model responds to the need of integrating heterogeneous information on a geographical basis which are currently scattered across many providers, i.e., institutional portals, organizations websites, Facebook pages, etc. On the other hand, the possibility of filtering information by space (map zoom and bounding box), time (timeline and global calendar), and content (properties, tags and categories) tames the complexity of overcrowded maps. Furthermore, entities are updated in real-time to facilitate coordination and planning at multiple scales (neighborhoods, districts, city) and at different time intervals (hours, days, weeks, months).
36 J. Roschelle and S. D. Teasley, “The construction of shared knowledge in collaborative problem solving,” in Computer supported collaborative learning. Springer, 1995, pp. 69–97
35
CO3 Project D2.1 In FirstLife, differently from other social networks, users cannot be followed directly, also considered the sensitiveness of privacy issues concerning the position of users. Relations within the users' networks are created indirectly via their interaction with the map entities. FirstLife provides a basic decision support system favoring public and private organizations, as well as citizens, to easily access information about: past, present and future events and the main transformations that are taking place in cities directly on an interactive map. The integration with other CO3 disruptive technologies will improve the degree of coordination offered by FirstLife.
3.4.2 Cooperation By defining groups as entities, FirstLife addresses the management of task/activities based on the mutual awareness of what is happening in a common information space where people are working together for a limited period and for a specific goal. The added value of groups stands in the opportunity they give to each group's member to be constantly updated about changes in their specific information space. A group map can be seen as isolated from the other data showing only what is needed to be known by the group itself. At the same time, all contents added by groups' members are public favoring intra- and inter- group coordination. Besides groups, cooperative work is addressed by the introduction of PlacesLists within the model. They allow to associate entities of every type to a specific PlacesList carried out by the users. As in the case of the group entity, PlacesList allow for the filtering of information related to that particular task or activity, i.e., cleaning up the neighborhood's park. In light of this, while groups are more adequate when the coordination task/activity is delimited in time and space and involves a specific group of users, PlacesList are more open, favoring a broader people engagement in participating in the work. Within the CO3 project, FirstLife will also improve functionalities of groups entity type: motivated by pilot sites inputs and requirements, the platform will be enriched with non-public groups, in which membership can be required by users, or provided by an invitation from group administrators. The definition/constitution process of group administrators will be defined at the end of the feature identification process. Moreover, an integration between FirstLife groups and LiquidFeedback Units is foreseen.
3.4.3 Collaboration The definition of the content-based relational model led to the implementation of a collaboration framework where users could be made more aware of the different or shared perspectives on the same entity. Although the essence of a crowdsourcing platform is that every user can contribute with her own viewpoint, the perceived “right” to write about a place or an event may determine uncertainty about who is more entitled to provide the most basic characterization of an entity. To overcome this problem FirstLife introduced nested entities: a hierarchy between first order entities that have a hidden initiator, and second order entities each of them belonging to a different author who is responsible for moderation only about her specific contribution.
36
CO3 Project D2.1
3.5 Technical Details The FirstLife's development process follows an Agile methodology with very fast sprints, in order to maximize the delivery, implement and test new features in accordance with the timing of different projects. FirstLife has been used in many scenarios with different characteristics, involving large numbers of users.
3.5.1 FirstLife FrontEnd The FirstLife client is represented by a web application that can be easily used both from desktop and mobile devices, thanks to responsive design programming. The frontend is developed by using Angular >8.x, while maps leverage the functionalities offered by OpenLayers framework and the FirstLife tile server.
3.5.2 FirstLife Backend The backend of FirstLife is developed using LoopBack, a NodeJS based framework that provides a model-oriented approach in which the definition of a high-level data model allows the framework to offers to the user an abstraction layer between the business logic and database technologies. In this manner, Loopback can support in a seamless way, different storage technologies, like relational databases, NoSQL, in-memory, etc.
3.5.3 FirstLife Resource Server As described in the Conceptual Model section, actually FirstLife entities can be enriched with second-layer entities like comments, images, documents, polls, and the list of the tools is constantly growing. With the objective of serving external resources, FirstLife team designed and implemented a new Resource Server that is able to store, process and expose via URI all external content that users can use to enrich first-level entities. Actually, the FirstLife Resource Server supports the storing of images, and pdf documents, but, during the CO3 project, this list will include more file formats like audio files and 3D models, that will be retrieved by AR mobile app after the geographical localization of the user.
3.5.4 FirstLife API The backend can be invoked by the client or third-part applications via API REST. FirstLife APIs uses a JavaScript Object Notation JSON as message format, in particular an extension of JSON meant for geographical entities: GeoJSON . GeoJSON is a standard format for geographical data, supported by all major GIS (geographical information system) and web GIS software. The API layer is supported by an access control layer ACL defining users’ permissions over contents. The user authentication within the CO3 project is provided by the aforementioned Unified CO3 User Management module. The same module is also responsible for authorization tasks, implementing the well-known OAuth 2.0 Authorization Code flow pattern.
37
CO3 Project D2.1
3.5.5 FirstLife Tile Server InputMap and AreaViewer require access to a common source of geographical data to render an interactive layer on a web map. In order to provide a fast and standard access to web map components from all CO3 softwares, a tile server developed and deployed by FirstLife team is available. The FirstLife TileServer provides geographical entities in vector tile format 2.1 ( https://www.mapbox.com/vector-tiles/specification/ ), an open source format widely used to provide vector tiles, and it is based on OpenStreetMap data. TileServer is an ExpressJS 37
application, using libraries and tools developed by Mapbox and Leaflet communities.
3.5.6 Localization FirstLife is already available in English, Italian and Greek. Within CO3, French and Greek will be mandatory, and will be added with the contribution of the other partners.
Language Partner Contributed Published
French IRI foreseen foreseen
Greek DAEM foreseen foreseen
Italian UNITO ✔ ✔
37 https://www.openstreetmap.org/
38
CO3 Project D2.1
4. Exchange System based on Blockchain
4.1 Introduction The blockchain exchange system, which is developed in this consortium is an API and an aggregation service running on top of an Ethereum-based blockchain. This exchange system intends to facilitate a number of different functions as part of the unified app. In the following, we list a number of major actions and services that the exchange system enables users to do:
1. Create and register users and organizations 2. Create, update and restore user keys 3. Create tokens 4. Transfer tokens to other users and organizations 5. Receive tokens 6. Create, deploy and interact with Smart Contracts
4.2 The Blockchain Network: Hyperledger Besu The exchange system will be implemented as a blockchain-based on the Proof-of-Authority (PoA) consensus mechanism. In a system based on Proof-of-Authority consensus only a restricted 38
number of nodes, known as sealers, has writing permissions and is allowed to add blocks containing transactions to the blockchain. Due to the nature of the project – a central permissioning while keeping the infrastructure cost low is required – PoA is deemed the best candidate for the consensus algorithm to be used. One of the most prominent Ethereum client implementations that allows for the use of PoA consensus models is 'Hyperledger Besu'. Hyperledger Besu is an open source Ethereum client developed under the Apache 2.0 license and written in Java. It can be run on the Ethereum public network or on private permissioned networks, as well as test networks such as Rinkeby, Ropsten, and Görli. Hyperledger Besu includes several consensus algorithms including Proof-of-Work, Proof-of-Authority, and IBFT and has comprehensive permissioning schemes designed specifically for uses in a consortium environment. Moreover, Hyperledger Besu implements the Enterprise Ethereum Alliance (EEA) specification.
4.3 Key & User Management Blockchain systems are characterised by their strong security measures. This is implemented by two important concepts: public and private keys. Public keys act as identifiers of users of any blockchain exchange system (within the system) while private keys remain confidential to the user and can be used to sign/authorize transactions. The consortium is dealing with key and user management in ways slightly different from how they are managed in typical blockchain exchange systems. This is due to the audience and users of the app, namely non-tech savvy individuals. Their level of tech literacy gives rise to issues such as loss of private keys which can in turn lead to loss of funds and inability to interact with the unified app.
38 https://github.com/paritytech/parity/wiki/Proof-of-Authority-Chain
39
CO3 Project D2.1 To overcome the above-mentioned issues, we have planned to implement ‘multisig' wallets. On Ethereum protocol, a multisig wallet is a smart contract with a set of requirements to move funds or interaction rules to connect with other smart contracts. They may require signatures from a number of authorized addresses to be considered valid and true. These authorized addresses can be managed by a single, multiple individuals or even an organization. Our implementation of multisig wallet will allow for one signature (of the sole holder of the wallet) to be valid for processing transactions. However, it has the capability of adding multiple keys for safe-keeping of funds and tokens. Multisig features will be updated considering the state of an evolving regulatory landscape with respect to private keys custodial solutions.
Figure 2 – Schematic of the initial setup of the multisig
4.4 Tokens as enabler of transactions in blockchain exchange systems Cryptographic tokens are programmable assets or access rights that are primarily managed by a smart contract and a blockchain as infrastructure. They can be accessed only by the individual who is in possession of the private key for that address and can only be signed using the very same private key. Tokens give access rights to an array of underlying economic value (such as property rights) or permission to access the property or services of someone else or even collective goods. Due to the dynamics of the pilot sites and various user scenarios, there is a clear need for different types of tokens: fungible and non-fungible. These tokens, depending on the pilot sites,
40
CO3 Project D2.1 can be used to book classes, buy goods and services or define writing/access rights to the augmented reality and geolocated slots of data. To reduce the confusion of users, tokens to be used for different purposes will be categorized accordingly. This means that there will be different types of tokens accessible and usable in the blockchain exchange system.
4.5 Blockchain wallet As an interface between the user and the blockchain exchange system, we will develop a wallet web app that allows the management of public and private keys as well as funds in the form of tokens. The wallet will be following principles of progressive web app and will be embedded within the unified CO3 app. Other CO3 components can trigger actions in the blockchain wallet using the ‘deep linking’ feature to be enabled by the design of the wallet. Deep linking is the use of hyperlinks to link to particular pieces of web content on a website or an app.
4.6 Blockchain contracts Answering the necessities of the Commons economics, the blockchain exchange system will offer a list of different kinds of smart contracts that enable different logics. For instance, crowdfunding/ crowdsale contracts that receive one kind or a combination of tokens such as prepaid tokens and discount tokens and send another token or a combination of tokens representing coupons and cashback. In regards to crowdfunding, the contract sends tokens only if a certain global contribution is met, otherwise subscribers can request reimbursement. Crowdfunding can be used to gauge users preferences on the initiatives proposed. Moreover, virtual vending/exchange machines that receive one kind or a combination of tokens and give back tokens, will allow individual exchanges between different tokens. The virtual vending machines can be equipped with a limited amount of tokens for sale, e.g. third party tokens.
4.7 Blockchain space economy The economics of the augmented layer will mimic an open access resources by allowing users to overwrite on previous content. We expect this will stimulate the communities to devise mechanisms for appropriation and redistribution of the commons’ value . It will be possible to 39
pick up (e.g. by posting content on the augmented space, the user will be able to pick up a reward) and drop various kinds of tokens in correspondence with spatial locations. Tokens will also be used for allowing reading rights to content posted in Augmented Reality (e.g. pay per view buttons).
5. Opinion formation with Interactive Democracy In CO3 interactive democracy, the application of the internet for democratic processes, is represented by LiquidFeedback. This chapter describes LiquidFeedback, how the wide range of configurations options will be used and which specific extensions will be created during CO3. LiquidFeedback will also provide the unified user management described in chapter 2 and will be responsible for the implementation of the accreditation process.
39 Elinor Ostrom “Governing the Commons, Indiana University press, 1990, Bloomington
41
CO3 Project D2.1
5.1 LiquidFeedback for deliberation and decision making LiquidFeedback is a web application for the democratic self-organisation of large scale groups. It combines concepts of a collectively moderated, self-organized discussion process (quantified, constructive feedback) and transitive proxy voting (liquid democracy). LiquidFeedback covers the process from the introduction of the first draft of a proposal to the final decision. This way it allows to participate not only in voting but also in developing ideas. Discussing an issue before voting increases the awareness of pros and cons, chances and risks, and allows people to consider and suggest alternative trade-offs which can become part of the final voting procedure. Extra effort has been made to ensure minorities can express their view and stay visible. On the other hand, LiquidFeedback can also handle the challenge of noisy minorities. A three minute video introduction narrated from the user perspective can be found at https://liquidfeedback.org/.
5.1.1 Democratic self-organization LiquidFeedback is a proposition development and decision making system for the democratic self-organization of large scale groups such as political parties, civil society organizations or as an additional channel between citizens and their administration.
The LiquidFeedback proposition development and decision making process. Deliberation (green) before voting (blue). Source: Interaktive Demokratie e. V..
A deliberation phase before the actual voting makes sure pros, cons and alternatives can be considered, transitive proxy voting - sometimes referred to as Liquid Democracy - allows for a dynamic division of labor based on individual choice and for proportional representation. Because of an effective collective moderation by all participants there is no need for a moderator or request commission . LiquidFeedback's proportional representation and algorithms such as proportional runoff and harmonic weighting make sure minorities can express their points of view according to their actual size. At the same time LiquidFeedback protects against the dominance of noisy minorities, hate speech and trolling.
42
CO3 Project D2.1 A clone-proof preferential voting determines the collective preference. The proposition development process is fully transparent using a recorded vote and can be reviewed by all participants. All decision relevant states are available both human and machine readable to ensure a credible process with trustworthy and indisputable results. In the following we discuss two possible usage contexts within the CO3 project: LiquidFeedback for citizens (civic participation) and self organization of communities.
5.1.2 Civic participation - LiquidFeedback for citizens There is a lot of discussion about civic participation, usually because of an actual or assumed lack of representation. However, the demand for civic participation appears to be highly selective in terms of the subjects and the interest groups involved. Referenda seem to be a legitimate way, but they are not always possible and have their own shortcomings. A binding civic participation system would require a general agreement within the population or a law for that matter. It would also impose high technical requirements and wouldn’t allow secret voting which would have to be done outside this system, i. e. in a separate referendum. As of now, one approach is establishing an additional communication channel between voters and their administration— very similar to the idea of petitions. The representatives are to make responsible decisions based on the popular vote. A typical way of giving such a system a more “binding” character, is the commitment of a legislative body to deal with every winning initiative in a parliamentary session and thus allowing agenda setting to citizens. This is to build trust in the administration’s work and to contribute to the perception of accountable politics. In the context of CO3, such a commitment by the local administration will be necessary to allow the disruptive character of LiquidFeedback to unfold. Consequently, existing implementations show a tendency of representatives to become more communicative by explaining politics both in the debate and following the decision. Such a system should be a permanent offer to the citizens and be regarded as democratic infrastructure—ready to use whenever the need arises. The sole existence of such a system can affect the relationship between citizens and public administration. But internet based participation systems like LiquidFeedback can also help to overcome the limitations of a referendum: LiquidFeedback can be used to prepare a referendum as it allows to consider pros and cons, to enhance propositions, and to suggest alternatives. If alternatives exist, its preferential voting can be used for the preselection of the question to be asked in the actual referendum.
5.1.3 LiquidFeedback for the self-organization of communities A second usage environment we can foresee in the scope of the CO3 project is self organization of associations, communities or other defined groups. Binding self-organization allows the disruptive character of interactive democracy to unfold. Universally applied to all decision processes within an organization LiquidFeedback can challenge existing power structures and hierarchies. Furthermore, liquid democracy addresses the well known problems of direct democracy. The “executive branch” within an organization remains necessary but with re-defined dynamics and roles.
43
CO3 Project D2.1
5.1.4 Isolated use cases versus permanent participation infrastructure LiquidFeedback is designed to provide a permanent participation infrastructure. Municipalities sometimes think in terms of calls or use cases. Considering the substantial effort necessary to provide a credible participation process, the (isolated) use case approach is not efficient nor sustainable. However, it is possible to combine both approaches by using calls and use cases to populate a platform which ideally is used for a variety of both, bottom-up and top-down participation processes.
5.2 Aspects and objectives of LiquidFeedback
5.2.1 Transitive proxies (liquid democracy) One distinct feature is the support of a dynamic division of labour based on individual choice: Voters can delegate their vote to a trustee (technically a transitive proxy). The votes can be further delegated to the proxy’s proxy thus building a network of trust. A dynamic scheme of representation takes place. Anyone can select their own way ranging from pure democracy on the one hand to representative democracy on the other. Basically one participates in what one is interested in but for all other areas delegates their vote to somebody acting in their interest. The division of labour – specialization and cooperation – is part of the success story of the human species. Over the centuries division of labour has become increasingly complex and no modern society can exist without. Representative democracy constitutes a division of labor in the field of politics. Transitive proxy voting (liquid democracy) makes division of labor available to the voters. While representative democracy remains static, liquid democracy offers a dynamic solution. All delegations can be done, altered and revoked by topic. A dynamic scheme of representation takes place. In LiquidFeedback delegation can be given
● for all issues in all subject areas within an organisational unit (e. g. counties, districts, boroughs or parts thereof),
● for all issues in a particular subject area (e.g. “traffic”) of an organisational unit, ● for a single issue, which is a group of already existent competing proposals to be voted
upon together.
44
CO3 Project D2.1
Delegations: An unfolding transparent and responsive power structure within an organisation.
Source: Interaktive Demokratie e. V. Delegations are not only applied to the final vote on a given issue but also applied during its discussion, where it is possible to rate other people’s proposals. Whenever a more fine- graded delegation exists (e.g. a delegation for a particular issue), a more general delegation (e.g. a delegation for the respective organisational unit) is overruled for the affected subject area or issues. The same holds when you make use of your own vote: If you enter a discussion by supporting or opposing proposals or make your own proposals, then you can’t delegate your vote during discussion. If you participate in a final voting, you can’t delegate in that final voting. Any form of direct participation will suspend existing delegations. A proxy can not vote in the presence of the principal. Within CO3, transitive delegations should be enabled for scalability but a practical impact can only be expected in a setting with hundreds of open decisions at any given time. This would, however, be untypical for emerging civic participation.
5.2.3 Collective moderation Democratic processes inside organizations are traditionally organized by a chairman, a “request commission,” or similar institutions. As LiquidFeedback aims to allow every participant to gain equal rights and chances in the decision process, LiquidFeedback generally abstains from empowering one or multiple participants to have any special privileges for moderating a dis- cussion or decision-making process. Instead, moderation is done in a collective process where every person has equal rights.
5.2.4 Minority protection Democracy means that decisions are made by a majority. Every decision without unanimous assent leads to an overruled minority. Nevertheless, minorities can and must be protected in certain ways:
45
CO3 Project D2.1 First of all, most democracies grant their people unalienable rights which can’t be abolished even by a majority of the parliament. This form of protection can’t be ensured algorithmically and thus is by principle out of the scope of LiquidFeedback or any other decision system. Fundamental rights need to be enshrined in a constitution, party statutes, etc. and carried out by humans who judge about every single case. Another form of minority protection can be implemented algorithmically though: In a democracy every group (including minorities) must have the chance to promote their positions. It is vital for a democracy that groups consisting of less than 50% may propose alternative proposals, which are then presented and discussed in an adequate way. In general meetings or party conventions the presentation of such minority viewpoints is classically done by assigning discussion time. But using an internet based system like LiquidFeedback allows us to have a huge amount of proposals in discussion in parallel. However, when a huge number of people wants to put a huge number of proposals to discussion, a limited resource is the placement on the screen. In an online system we thus do not allocate “discussion time” but “display positions,” i. e. we determine a fair ordering when listing different
● issues within a subject area, ● initiatives for an issue, or ● suggestions for an initiative.
LiquidFeedback ensures that every minority gets a fair share according to their actual size. To 40
accomplish this, LiquidFeedback applied algorithms such as Harmonic Weighting (Thiele’s Elimination Method), Proportional Runoff as well as the proportional representation provided by transitive proxy voting (and debate empowerment). 41 42
5.2.5 Noisy minorities A phenomenon often observed is that proposals seem to be highly controversial when discussed on media like mailing lists and yet gain a huge majority for or against them when they are finally voted upon. One reason for this effect is the correlation between the sensed collective opinion and the motivation to engage in a debate. This correlation colludes with the fact that in discussion threads a lot of text may be posted without being rated by all participants. Such postings are yet taken into account when participants judge about the current state of the discussion. This sometimes yields to a deceiving equilibrium of opinions, where it seems that there are approximately 50% of the participants in favor of and 50% of the participants against a proposal, independent of the real distribution of opinions. Depending on the discussion media, noisy minorities may cause people to sense a widespread public opinion which in fact is just argued by a small minority. Noisy minorities can unless certain measures are taken cause a big harm to democratic decision-making processes, as people are
40 Brill, Elkind Lackner, Peters, Skowron: Proceedings of the Twenty-Sixth International Joint Conference on Artificial Intelligence (IJCAI-17), https://www.ijcai.org/proceedings/2017/0058.pdf 41 Svante Janson: Phragmen’s and Thiele’s Election Methods, Department of Mathematics, Uppsala University, Uppsala, Sweden, 2018, page 15, https://arxiv.org/pdf/1611.08826v2.pdf 42 Svante Janson: Thresholds Quantifying Proportionality Criteria For Election Methods, Department of Mathematics, Uppsala University, Uppsala, Sweden, 2018, page 69, https://arxiv.org/pdf/1810.06377v1.pdf
46
CO3 Project D2.1 misled regarding public opinion. In addition to creating a biased impression on majority stakes, a noisy minority can drown the viewpoints of other minorities which are less noisy. LiquidFeedback relies on the proportional representation algorithms as discussed in under minority protection. These algorithms do not empower majorities to silence minorities, but they assign each minority a fair share of attention independent of their agitation. Of course, these algorithms as well as the final voting procedure may only be fair, if it is ensured that one person may not get more than one account in the system
5.2.6 Preferential voting LiquidFeedback uses Clone Proof Schwartz Sequential Dropping (Schulze Method), a single-winner preferential voting system which fulfills a number of desired criteria, including:
● Independence of Clones ● Monotonicity ● Reversal symmetry ● Taking majorities into account by always selecting a member of the Schwartz set as
winner ● Independence of Smith-dominated alternatives (ISDA or Smith-IIA)
The Schulze method is a single-winner system always selects one winner based on the voters’ preferences. As it is also a valid outcome that no initiative is resolved upon, i. e. status quo wins. LiquidFeedback internally converts the preferential ballots with approval and disapproval section of each voter in such a way that the added status quo is ranked below those initiatives which the voter approves and above those initiatives which the voter disapproves. At the end of the voting phase, these converted ballots are counted using the rules of the Schulze method to determine the winner of the final voting. The Schulze method determines a winner by comparing every alternative with every other alternative (including the implicitly added status quo). The comparison of two alternatives X and Y is done in such a way that for every voter it is counted whether this voter prefers X to Y , prefers Y to X, or is indifferent about them (i.e. ranking those alternatives equally). If more voters prefer X to Y than there are voters which prefer Y to X, then we say X defeats Y in pairwise comparison. If there is exactly one alternative which defeats all other alternatives in pairwise comparison, then this alternative is the winner. Unfortunately, there are cases when no alternative defeats all other alternatives. In these cases, it is still possible to determine the smallest non-empty set of alternatives which are not defeated by any other alternative outside this set in pairwise comparison. This set of alternatives is called the “Schwartz set,” due to Thomas Schwartz, who discovered this set. The winner selected by the Schulze method is always one that is contained in the Schwartz set. When there is more than one alternative in the Schwartz set, then the Schulze method determines a winner as follows: All candidates that are not in the Schwartz set are eliminated and won’t be considered anymore. The weakest pairwise defeat between non-eliminated candidates is replaced
47
CO3 Project D2.1 by a pairwise tie. The Schwartz set is re-calculated, considering only the non-eliminated candidates. The whole process is repeated until the Schwartz set contains only one candidate, which is then declared winner. In order to determine the weakest pairwise defeat, it is necessary to define the strength of a defeat. There are different ways to do it, and LiquidFeedback follows Markus Schulze’s recommendation to primarily measure the strength by the winning votes and secondarily by the opposing votes. In other words: The weakest pairwise defeat is the defeat with the fewest votes for the winner of the pairwise defeat, or—if there is more than one pairwise defeat fulfilling this—that defeat with the fewest votes for the winner and the most votes for the loser of the pairwise defeat.
Tie-breaking In almost every voting system there is a possibility of ties between candidates (in our case: between proposals). In a few rare cases you can avoid ties, e. g. when deciding on two alternatives and having an odd number of voters where abstention is not allowed. Of course this can’t be generally assured. Nevertheless, for most voting systems the probability of ties fortunately tends to zero as the number of voters increases, which is also the case for the winner of the Schulze Method. Ties are still possible though, and LiquidFeedback needs a way to deal with them. While ties are usually resolved by a second ballot or by drawing lots, neither of these approaches is suitable for LiquidFeedback: A second ballot could cause a massive delay of the determina- tion of the final winner, as the voting phase would need to be repeated, which might take days or weeks according to the policy that is in effect. Depending on external time constraints, this could practically result in no decision to be made in time, thus preferring the status quo in case of ties, which is not desired as there might be a huge majority for changing the status quo. The other option, drawing lots (i. e. randomness), is also not an option because LiquidFeedback aims to provide results that are verifiable by the participants. Using a random generator could not be verified by the participants unless its mechanism were to be sufficiently simple and used in a public meeting (e. g. coin toss at a meeting of the members). Due to these practical obstacles, LiquidFeedback needs to resort to other means of tie-breaking. One possible approach is to give priority to the pair-wise comparison of all proposals with the status quo (i.e. letting those proposals win which perform better when compared to the status quo). However, such a solution still can’t solve all ties (e. g. those ties where two different pro- posals are simply ranked equally on all ballots) and furthermore could give voters an incentive for tactical voting, as approving or disapproving a proposal in comparison with the status quo would have an important effect in those cases where there is a tie between two proposals. For the reasons explained above, LiquidFeedback falls back on a very simple mechanism for breaking ties: In case of a tie, the initiative which was entered first wins. While this approach may appear arbitrary, there is a reasoning behind it: Assuming a system where there are ballots about change requests, a tie usu- ally means that the change request is not approved and thus the previous proposal is kept. Both LiquidFeedback’s approach and change requests yield to the same result, where that initiative wins that was created first. To not discourage initiators to update their drafts, it is always the creation time of the first draft that is taken into account for tie-breaking between initiatives.
48
CO3 Project D2.1
5.2.7 Supermajority requirements LiquidFeedback allows to require supermajorities. In general, supermajorities can have a justification when it comes to ensuring stability, e.g. for the amendments of statutes. Consequently, supermajorities can typically be found in LiquidFeedback policies which aim at changing the charter of an organization. However, supermajorities usually don’t work in favor of minorities and they impose democratic deficits. Only majority rule satisfies political equality . In the scope of the CO3 project and in civic 43
participation in general, partner LiquidFeedback recommends to refrain from using supermajority requirements.
5.2.8 One individual - one vote The principle “one individual - one vote” is the most fundamental requirement for any 44
democratic process. An accreditation process has to ensure that only entitled persons get access to the system with exactly one account.
5.2.9. Voting weight based on blockchain tokens As opposed to the one individual - one vote in democratic decision making, CO3 also foresees certain voting processes with the voting weight determined by available tokens. The discussion between the involved partners and the envisaged solution are documented in the unified feature list.
5.2.10 Trustworthiness The outcome of self-organization or participation will always have an impact on the real world (if not, the participants would have no real influence, which would contradict the goal of any form of self-organization or participation). Unquestionable, real influence on shaping the future brings up different attempts of a beneficial takeover. Therefore, manipulation or fraud attempts have to be expected in any phase of self-organization or participation. When a self-organization or participation process can withstand against such illegitimate influence it can be called trustworthy. A trustworthy process can prevent, detect and handle attempts of manipulation and fraud. The trustworthiness of the processes within LiquidFeedback originates from the combination of two strategies:
● Full transparency of any activity in the system. 45
● Identifiability of all participants
43 Anthony J. McGann: “The Tyranny of the Super-Majority: How Majority Rule Protects Minorities”. Published 2002 by University of California, Irvine, USA. http://escholarship.org/uc/item/18b448r6 44 In the literature, this principle is often also referred to as “one man - one vote”. 45 Any action of a participant in LiquidFeedback is visible to any other participant of the same installation. Additionally, public access can be configured.
49
CO3 Project D2.1 The first strategy is inherent to LiquidFeedback. Every activity which is relevant for the procedure is made public after been carried out, including:
● Authors of initiatives and suggestions ● Support or opinions given ● Vote delegation ● Voting ballots
The second strategy requires a proper accreditation of any participant. This is discussed in the section “Accreditation”.
5.2.11 Existing gamification aspects in LiquidFeedback LiquidFeeback integrates some gamification elements. The most relevant are those that appeal to the socializers. Those elements motivate these users to interact with others because they perceive themselves as important among the community as their proposals gain popularity and support.. Initiative creators or suggestions authors can gain satisfaction by a growing supporter count for their proposals which is visualized as a growing green chart bar (if the proposal is purposeful and creates resonance). Good work is rewarded.
Source: FlexiGuided GmbH
Over time a user builds a reputation which is reflected by the information in the user profile.
5.2.12 Geospatial extension of LiquidFeedback pgLatLon, a geospatial database extension for the PostgreSQL object-relational database 46
management system, is available which can be used to build proximity based search requests on the data stored in LiquidFeedback. pgLatLon provides geographic data types and spatial indexing for the WGS-84 spheroid. While many other spatial databases still use imprecise bounding boxes for many operations, pgLatLon aims to support precise calculations for all implemented geographic operators. Efficient indexing of geographic objects is provided using space-filling fractal curves. Optimizations on bit level (including logarithmic compression) allow for a highly memory-efficient non-overlapping index suitable for huge datasets.
46 https://www.public-software-group.org/pgLatLon
50
CO3 Project D2.1
5.3 Structure of LiquidFeedback
5.3.1 Organizational units LiquidFeedback allows a setup where different organizational units of an organization have their own zone within the system. Voting rights for a person can be restricted to that set of organizational units where the person is a member of. Each organizational unit can have one or more “subject areas” within the system. The organizational unit is the highest level for a “delegation”. In civic participation, organizational units can also refer to different territories, e.g. Aubervilliers, Épinay-sur-Seine, L’Île-Saint-Denis, La Courneuve, Pierrefitte-sur-Seine, Saint-Denis, Saint-Ouen, Stains, Villetaneuse, and Plaine Commune where a citizen of Saint-Denis would have voting rights in Saint-Denis and Plaine Commune. Plaine Commune and the single municipalities could have their own sets of subject areas. Organizational units allow to structure and cater complex needs. However, if this complexity is not needed LiquidFeedback can be operated in single-unit-mode reducing the complexity of the user interface. Within CO3, the LiquidFeedback unit concept will be used as a general authorization scheme for providing privileges to authority defined groups, i.e. the public administration assigns certain user privileges to members of a group. Units shall be adopted as a global concept in CO3, e.g. only members of a specific unit can map an area in FirstLife. Furthermore, the group concept of FirstLife is applied for self-defining groups, e.g. users can join and leave a group based on certain criteria or providing they meet necessary preconditions. LiquidFeedback plans to mirror groups into units. Throughout the platform, this will allow to provide privileges to users based on their group membership, e.g. voting rights based on group membership. Details on the foreseen global application of the group and unit concepts can be found in the unified feature list.
5.3.2 Subject areas Each “organizational unit” may have several subject areas, in which issues are discussed. Subject areas may refer to certain policy fields, e.g. Communities, Education, Events and Culture, Highways, Housing, Local Economy, Parks and Leisure, Planning Policy, Public Health, Regeneration, Youth Services and/or to specific participation calls or projects, e.g. the 2024 Olympics village. In civic participation it is essential that citizens who want to start an initiative can easily determine where the issue belongs. Municipalities often opt to mirror their own administrative structure but this may not always be intuitive. Additional subject areas may be added in the process, e.g. for new participation calls. If the subject area is not needed, LiquidFeedback can also be operated in
51
CO3 Project D2.1 single-area-mode in order to further reduce the complexity of the user interface. The subject area has an effect on the “delegations” that are in effect for a particular issue.
WP / Task Negotiation partner Action point
WP3 LF / DAEM and pilot sites
For each scenario and organizational unit, decide if multiple subject areas are needed. Provide the list of subject area names.
5.3.3 Policies Different timings and quorums might be suitable for different kinds of decisions. Moreover, in some contexts there might be supermajority requirements during final voting, as for example changing the statues of some organizations requires 2/3 of the votes to be in favor of the motion. To allow different values for timings and supporter quorums, and to allow the possibility of supermajority requirements for certain decisions, LiquidFeedback allows its users to have so called “policies” for different kinds of decisions. For civic participation it is usually advisable only to offer one policy per area for citizen initiated issues.
5.3.4 Database scheme
LiquidFeedback Core 4.0 database scheme (simplified) Source: Public Software Group and FlexiGuided GmbH
52
CO3 Project D2.1
5.4 Roll-out preparation
5.4.1 Technical requirements
Participant (user) LiquidFeedback can be used like a website with a web browser. It has been tested on a variety of different browsers, including mobile browsers. JavaScript and Cookie support should be enabled. To register an account, a working email address is needed.
Municipality The backoffice area, where participants can be accredited is an integral part of LiquidFeedback and can be used as a website with a web browser. It has been tested on a variety of different browsers. JavaScript and Cookie support should be enabled.
5.4.2 Localization LiquidFeedback is available in a couple of EU/EEA languages. Within CO3, French, Greek and Italian will be mandatory. While Italian has already been contributed by UniTo staff during the course of a previous H2020 project (WeGovNow), further localizations are provided by the respective native speakers within the CO3 project. In the run-up to the localization, LiquidFeedback has set up a development and training system for CO3 in March 2019 and organized a webinar in order to provide hands-on experience with LiquidFeedback for a better understanding of terminology and to promote consistency of the translation. The webinar was attended by CTO, DAEM, OLA, UniTo and UVIC. DAEM has already contributed the Greek localization, DAEM, OLA and LF have jointly completed the QA/QC process. UVIC has contributed a Spanish (Castilian) localization, QA/QC for Spanish is ongoing. IRI will provide the French localization. The translating partners use either an individual or corporate contributor license agreement (CLA)
with the Public Software Group. To ensure the sustainability of the performed EU funded work, 47
the translations will be made available to the world.
Language Partner CLA Contributed Published
French IRI ✔ foreseen foreseen
Greek DAEM ✔ ✔ foreseen
Italian UNITO 48 ✔ ✔ ✔
Spanish FUB ✔ ✔ foreseen
47 See Annex PSG-CLA (individual and corporate) 48 During the course of a previous H2020 action (WeGovNow)
53
CO3 Project D2.1
5.4.3 Accreditation LiquidFeedback can use an existing subscriber database, e.g. a national voter register, or provide a configurable voter registration and accreditation process.
WP / Task Negotiation partner Action point
T1.3 WP3
LF / LINKS LF / DAEM and pilot sites
Decide on a technical and practical feasible accreditation process ensuring that
● only eligible persons can participate ● every individual gets exactly one account ● participants can identify each other
WP3 LF / DAEM
Create correct documentation of the accreditation procedures reflecting the technical and ethical requirements in regard of democratic and trustworthy operation of opinion formation and decision making to ensure that any legal and ethical aspects have been considered.
5.4.4 Scalability LiquidFeedback has been used in scenarios with different user bases. From hundreds up to ten thousand and more of accredited users per installation (scenario). In certain scenarios, LiquidFeedback also served the computational load of very active user groups, with hundreds of users using the platform simultaneously. The CO3 proposal suggests some 40000 registered user accounts without providing a distribution between the pilot sites. To avoid operational risks, we assume this dimension per pilot site. Being far from mass participation and given the typical low activity level in civic participation, we don’t expect a great number of users simultaneously accessing LiquidFeedback. There will be no need for clustering or any other high load precautions for LiquidFeedback. However, this dimension requires efficient processes on the side of the public administrations and manual interactions, e.g. for credential recovery, need to be avoided wherever possible.
5.4.5 Sustainability, dependency and license management LiquidFeedback is published under the permissive MIT/X11 license. The entire stack of LiquidFeedback is available under permissive licenses (BSD, MIT/X11 et.al.). A fact sheet on the LiquidFeedback software, all dependencies and licensing can be found in the annexes of this document . 49
49 See annex LiquidFeedback license
54
CO3 Project D2.1
6. Augmented Reality interfaces
6.1 User Experience (UX) and User Interface (UI) The Augmented Reality interface and experience will be supported by the CO3 mobile app. The development of this mobile application aims to achieve the following goals:
● Develop a mobile platform that integrates all the technologies of the CO3 project to answer the research questions.
● Integrate Augmented Reality technology and interfaces to make it available to pilot participants.
● Create a “markerless” and multi-user Augmented Reality user experience. Augmented reality (AR) is an interactive experience of a real-world environment where the objects that reside in the real world are enhanced by computer-generated perceptual information, sometimes across multiple sensory modalities. Augmented Reality interfaces are an example of “Non-command user interfaces” in which tasks are accomplished using contextual information collected by the computer system, and not through commands explicitly provided by the user. To be able to interpret the current context and “augment” reality, an “agent” runs in the background to analyze the many external inputs and act on them, or provide actionable information. Markerless AR experience requires a more complex use of hardware sensors. It uses sensors to learn the position and orientation of the device. There are 3 sensors used in this type of AR:
● Accelerometer - measures the acceleration applied to the device, ● Gyroscope - angular speed around all axes in 3D space, ● Magnetometer - measures the ambient magnetic field in all axes.
To be able to ensure a good user experience and an accessible user interface of the CO3 mobil App, we will have to work on the following challenges:
● Accuracy - mobile device sensors are prone to bias. It means that the accuracy of displayed objects will be lower minute by minute. In newer devices the sensors are much more accurate.
● Battery - display on, camera on, orientation sensors, image recognition, GPS. These are considered the most energy consuming hardware in every mobile device. This means that interacting with augmented reality for even a few minutes can significantly drain the battery of the users.
● Accessibility - in 2018 Google released ARCore, the framework for creating AR apps. Although it’s well optimized and really cool, it’s supported on a limited number of devices. The list is growing, but currently it contains about 100 devices. It is currently the easiest way to create augmented reality apps.
The main User Interface elements of the CO3 project mobile application will be:
● HUD ● Device camera ● Wallet
55
CO3 Project D2.1
● QR code reader ● First Life information ● LiquidFeedback information ● Dashboard
Each of them is briefly described below.
6.1.1 HUD In video games HUD (Head-Up Display or head-up display, also known as status bar) is called the information that is always displayed on the screen during the game, usually in the form of icons and numbers. HUD usually shows the number of lives, points, level of health and armor, minimap, and others, depending on the game. Taking into account that the main interaction of the CO3 mobile app will take place through Augmented Reality, we believe that this approach to show information to the user is the most appropriate. Basically, gamification information will be displayed in the HUD of the mobile application. This will allow the user to have quick access to basic information and be motivated to interact with all the elements of the application.
6.1.2 Device camera The main UX element of the CO3 mobile app project will be the camera of the smartphones. It is an essential UX element for the proper functioning of the Augmented Reality markerless features because thanks to it the user can scan the environment so that the system can display or add digital elements in the real world. The user interface elements of the CO3 mobile App will be shown through the camera of the smartphone so that the user can interact with the corresponding commoning areas based on the pilot test in which they are participating.
6.1.3 QR Code reader QR codes can be read from the camera of the mobile device and will be used to launch activities from the CO3 platform that may or may not be related to Augmented Reality.
6.1.4 Wallet The wallet will be embedded within the CO3 mobile app and allow for a multitude of features and actions as exchanging tokens between users, and collecting virtual vouchers and coupons available in the AR view. This is done through two paths: APIs provided by the blockchain exchange system and deep linking features.
6.1.5 First Life As described previously, there is an ongoing discussion about possible deep integration features with FirstLife based on the FirstLife API specification which is still in development.
56
CO3 Project D2.1 The main goal is to show most of the events created in FirstLife and make them accessible through the CO3 mobile app using through the OnToMap API.
6.1.6 LiquidFeedback Augmented Reality CO3 mobile App will allow users to interact with the LiquidFeedback proposition development and decision making process. The full integration of features to a unified user interface is out of scope for this project. We will focus on some crucial features of the user interaction of Liquid Feedback to be integrated into the CO3 mobile app. Below we detail the most important functionalities detected according to the requirements of the pilot tests (see detailed description in section “2.6.3 Augmented Reality ↔ LiquidFeedback”):
● Display of LiquidFeedback initiatives as a marker in the Augmented Reality application ● Provide basic information related to LiquidFeedback initiative markers ● Provide further information related to LiquidFeedback initiative markers ● LiquidFeedback initiative markers linking to LiquidFeedback ● Support of a LiquidFeedback initiative from within the Augmented Reality application
6.1.7 Dashboard The dashboard is the user interface element that will show the basic information, as a summary, regarding the user information and the interaction of the users with the CO3 mobile App. In this dashboard users can see, among others, some of the following elements:
● User Information. ● Activity Log: a Landing Page shows events (interactions with all components) based on the
data provided by OnToMap. ● News: information, newsletters and notifications sent by Officers (PA or system operator)
to registered users. ● Gamification information: Although most of the information related to gamification will be
displayed in the HUD of the mobile application, the dashboard will allow users to view more details about it. In the dashboard the users will not only be able to see the points, the medals and achievements, but also the evolution of the same over time. Some of the gamification interactions are still to be defined but below we detail some examples:
○ Wallet creation/download ○ Creation of voting tokens ○ Consumption of voting tokens ○ Creation of fungible tokens (coins) ○ Consumption of fungible tokens (coins) ○ Add tag/multimedia object on-site ○ Add tag/multimedia object in 1L ○ Discover an AR object ○ Access in 1L ○ View initiative in LF ○ Voting tokens consumption ○ Start an initiative ○ Create a newsletter ○ Badges ○ Points
57
CO3 Project D2.1
○ Leaderbord ○ Level system
6.2 Localization The CO3 mobile app will show the information sent by other CO3 systems (LiquidFeedback and FirstLife) through OnToMap API (https://ontomap.eu/) in the language that has been used in the source applications. The strings (texts) of the mobile App will be shown depending on the favourite language set up at the users’ smartphone if those strings are available in this language. If don’t, strings will be shown in English by default. The CO3 Augmented Reality App will be localized to the most relevant EU/EEA languages prioritizing the following languages of the CO3 pilot sites and other CO3 partners.
Language Partner Contributed Published
French IRI
Greek DAEM
Italian UNITO
Spanish FUB
58
CO3 Project D2.1
7. Gamification layer
7.1 Gamification goals Gamification features and elements will be supported by the CO3 app, and more in general by the whole infrastructure of CO3. The development of these features and elements aims to achieve the following goals:
● to stimulate the first registration (onboarding) of the users to all the sub-systems implemented for each Pilot; this is a crucial aspect, while the CO3 onboarding should invite and gently push the user to complete the registration process
● to foster the platform’s usage and to increase – and measure – the users’ engagement, that can be detailed in interventions able to:
○ to encourage the users’ interaction with the ACA contents, and therefore with themselves
○ to encourage the frequency of the users’ visits into the ACA ○ to stimulate the actions on the sub-systems
7.2 Logging of activities for Gamification purposes The implementation of gamification elements and mechanisms are based on two main prerequisites, in order to allow the CO3 ecosystem to work properly and consistently:
● the ability to detect and recognize a defined set of events
● the ability to log and store event-related information, as previously detected and recognized
The OnToMap Logging service and Data Hub (CO3OTM), working as a cross-application logger of user actions and as a data hub for all the applications, offers support to fulfill both. The mobile app and all the other available touchpoints, as defined within each Pilot, will use data stored to update the user’s gamification elements and personalize the user experience. In respect of gamification aims, the overall CO3 approach in logging activities is to count rather than track events, preserving as far as possible the users’ privacy. A first, non-exhaustive, list of recognizable events is provided here:
● ACA related events ○ Access the mobile app while being inside the ACA area ○ Discover an AR object ○ Interact with an AR element (Pilot-wise actions) ○ Add an AR object
59
CO3 Project D2.1
○ Add a tag/multimedia (text/image/video/) object
● Wallet related events ○ Access the Wallet ○ Buy/sell/trade of coins ○ Consumption of fungible tokens (coins) ○ Creation of coins or fungible tokens (coins)
● First-Life related events
○ Access in FirstLife ○ View an instance in FirstLife ○ Enrich the content of an instance in FirstLife ○ Add an instance in FirstLife
● Liquid Feedback related events
○ Start an initiative in LiquidFeedback ○ Support an initiative ○ Suggest an improvement (enrichment) of an existing initiative ○ Assess an existing suggestion (for an enrichment) ○ Publish a new draft of an initiative (enrich/update an initiative) ○ Cast a vote (available after completion of voting phase)
The above listed events are currently reported to the OntoMap logger. They reflect activity with effect on the outcome. The limitation to these events is the result of the “privacy by design” guideline. In respect to gamification, additional events would be desirable such as:
○ Access/view a subject area, an issue or initiative ○ Access other information in LiquidFeedback
It should be discussed if and how these data could be provided (ideally also via OntoMap). This needs to be done considering the GDPR provisions providing a proper justification and would definitely require an update of the Data Privacy Statement (data categories).
7.3 Categorization of activities For each technology-related category, events can therefore detect activities with various levels of engagement and empowerment:
● Access (and correspondent first access) events are the baseline of the engagement level; the amount of accesses a user have performed from the beginning, or within a specific timeframe, can be used as the initial way of measuring her/his participation into the CO3 activities.
● Browse, Discover and View events give more insights about the actual usage of the system: how much the user is actually exploring the ACA or other available CO3 features,
60
CO3 Project D2.1
and can be used to understand how effectively the user is using one or more (or all) the available features.
● Interact and Enrich events give insights about activities where the user directly contributes to the ACA, adding or enriching content into the ACA and other CO3 available features.
● Buy/Sell/Vote events allow the CO3 system to track another category of usage, typically oriented to personal consumption of goods and services.
● Creating/starting/adding events close the circle, tracking activities that are showing a more in-depth involvement into the CO3 ecosystem. Some of these actions can be available only to a specific category of users, or can be accessible to users that have gained special status during their usage of the CO3 platform.
Example of CO3 generic actions categorized by level of engagement/empowerment
7.4 Roles, levels, thresholds and rules Roles identify the kind of engagement/empowerment within the platform. Typical labels used to identify such roles can be (from the literature): Newbie, Explorer, Builder, Architect. The transition from one role to another can be associated to the achievement of specific goals, like a certain amount (threshold) of events logged within a specific events category. Other rules can involve more categories at the same time, or consider only a time-limited set of events. On one side, and according to the specific Pilot’s scenario, each role can have a defined set of permissions to allow users with that role to have access to specific features/actions. On the other side, in a ‘flat’ implementation, levels are not used to give/limit access to specific features, but only to briefly describe the user’s profile and the kind of activities she/he does within the platform. In CO3 Pilots, such labels must be translated into proper and meaningful, Pilot-wise, definitions, like: Donors, Contributors, Peer-Consumer, Peer-Producer, Urban Commoner, Facilitator, etc. In CO3 Pilots, roles can also specifically address the gamification of public officers, where they can be described as Framers (a public officer that sets rules, monitors performance, and enforces
61
CO3 Project D2.1 compliance to ensure fair participation and boost participants’ confidence in one other), Sponsors (a public officer that provides inputs which participants cannot supply on their own — whether in the form of physical infrastructure or the rule of law) or Mobilizers (a public officer that organizes citizen efforts and sustains their involvement). Levels identify the expertise reached by the user; they can be related to specific role, or related to a specific application, or to the overall platform. Typical labels used to identify such levels can be (from the literature): Basic, Intermediate, Advanced, Expert, Guru. The transition from one level to another can be associated to the achievement of specific goals, like a certain amount (threshold) of events logged within a specific events category. As for the roles, each level can have or not a defined set of permissions to allow users with that level to have access to specific features/actions. In CO3 Pilots, such level labels can be translated into proper and meaningful, Pilot-wise, definitions. It is worth noting that the number of roles and levels will be defined by the Pilots. In a simplified approach, levels can be not implemented, from a user’s perspective. The suggestion here is to design the platform to at least allow this implementation, even if in a second step, if not meant from the beginning. Each Pilot will define roles, levels, thresholds and rules, according to its specific CO3 implementation. They will be stored in general OnToMap data structures. According to the number of events tracked in each category, users can move across different roles and expertise levels.
7.5 Visible gamification elements and applications layout Above roles and levels, other elements – visible elements – that will complete the gamification experience are points, badges and a leaderboard. Points are the synthetic representation of the activity logging, and follow defined rules, like a user gains 1 point each time she/he logins into an ACA, or into FirstLife or LiquidFeedback. Badges can be the visual representation of roles and levels, or of the achievement of a mix of specific thresholds of both. Leaderboard is the list of top performers inside an ACA, or inside an application, and can be constrained to time limitations (like all time, monthly, weekly, or even daily). Points and badges have a specific place in the upper side of the main layout of the CO3 application, to enforce the gamification aspects of CO3. This is a possible layout configuration:
62
CO3 Project D2.1
Example of a layout for the CO3 A/R App main screen
That portion of the layout will be populated through an API call that will retry the information requested for the visualization, like: a first string with the username, a first number representing the actual points, one or more pairs of text string and icon representing current role and level. The actual definition of the payload retrieved by the API calls will be defined in the details with Pilots. Graphical aspect (i.e. font face and size of the texts and icons) will be defined later within the Pilots and will be consistent across the different CO3 applications, that will call the API function and visualize the content accordingly, using online images or application assets.
63
CO3 Project D2.1
8. The System as a whole
8.1 Testing
Unit testing Unit testing where applicable will be performed by and in the responsibility of the individual developer teams.
Integration testing The interfaces between the applications will be verified in an iterative way as new components are integrated.
System and operational acceptance testing System testing and OAT will be performed in close cooperation with WP3. This task will also deal with the credibility of the voting processes and the CO3 platform in general. As all quantifications of user generated content constitute voting processes in a generalized sense, the tests will also look at all involved technologies in this respect. Potential threats, attack vectors and measures to avoid sock puppets, manipulation, and meddling will be explored. The data controllers will authorize necessary actions such as penetration tests. Finally stress tests according to the foreseen operational parameters will be conducted.
64
CO3 Project D2.1
8.2 Platform instances There will be five independently operated instances: A development and training system will be subject to continuous updates, a prototype instance will provide the latest available prototype, and the actual pilot instances in Athens, Plaine Commune and Torino. The pilot instances will be based on the latest available stable release (prototype). The pilot sites will run independent instances of the CO3 platform. There will be no interaction between the instances. Consequently, data of the pilot instances will be kept completely separate.
8.2.1 Development and training system A development and training system for LiquidFeedback has been installed in March 2019 and can be accessed at https://co3.liquidfeedback.com/. The system is used for webinars and workshops, validating the localizations and for the technical integration work. The LiquidFeedback instance provides the CO3UUM and integration framework. Usage of this system is restricted to staff of consortium partners. Therefore the self-registration is disabled and registration is by email invitation only. The OnToMap data hub and event logger was added in April 2019 by UniTo. FirstLife was added in October 2019 providing a second access point at https://co3.firstlife.org/. The components run on servers of the respective developer teams.
Component CO3 App Browser
Dashboard/Landing page ✎ Native Provided by GEOMOTION
✔ Website Provided by UniTo/FirstLife
FirstLife ✎ Embedded Pre-rendered by UniTo/FirstLife
✔ https://co3.firstlife.org/ Provided by UniTo/FirstLife
Blockchain ✎ PWA embedded in a WebView Unit 8 and UniTo/BC
✎ Wallet WebApp & PWA Unit 8 and UniTo/BC
LiquidFeedback ✎ Embedded Pre-rendered by LiquidFeedback
✔ https://co3.liquidfeedback.com Provided by LiquidFeedback
Augmented Reality ✎ Native Provided by GEOMOTION
n/a
Unified User Management ✔ Infrastructure Provided by LiquidFeedback
OnToMap Event Logger ✔ Infrastructure Provided by UniTo/OnToMap
Gamification Module ✎ Infrastructure Provided by LINKS and UniTo
65
CO3 Project D2.1
8.2.2 Prototypes The “First release of CO3 technological prototypes” (D2.2) is scheduled for 30.06.2020. It is foreseen to replace the prototype on 31.12.2020 by the “Second release of CO3 technological prototypes” (2.3). The “Final release of CO3 technological prototypes” (D3.4) is planned by the end of the project (31.12.2021). The components will run on servers of the respective developer teams. Detailed information on the individual prototypes will be available in an updated version of this document accompanying the demonstrators.
8.2.3 Athens The Athens instance will be operated by DAEM as data controller and data processor on DAEM servers. The developer teams will ensure the stable operation of their components, e.g. install updates. Should a developer team need to process personal data by way of exception this will be according to specific instructions by the data controller (supplemental data processing). The concepts of operation will be developed in cooperation with WP3 taking the specific situation of the Athens pilot site into account. The site specific information will be updated and reported along with the prototype demonstrators.
8.2.4 Plaine Commune The Plaine Commune instance will be operated by IRI as data controller and data processor on IRI servers. The developer teams will ensure the stable operation of their components, e.g. install updates. Should a developer team need to process personal data by way of exception this will be according to specific instructions by the data controller (supplemental data processing). The concepts of operation will be developed in cooperation with WP3 taking the specific situation of the Plaine Commune pilot site into account. The site specific information will be updated and reported along with the prototype demonstrators.
8.2.5 Torino The Torino instance will be operated by Città di Torino as data controller and data processor on municipality servers provided by UniTo as host provider. The developer teams will ensure the stable operation of their components, e.g. install updates. Should a developer team need to process personal data by way of exception this will be according to specific instructions by the data controller (supplemental data processing). The concepts of operation will be developed in cooperation with WP3 taking the specific situation of the Torino pilot site into account. The site specific information will be updated and reported along with the prototype demonstrators.
66
CO3 Project D2.1
8.3 Accessibility EU directive 2016/2102 regulates accessibility of the websites and mobile applications of all public sector bodies by 23 September 2019 (new websites), 23 September 2020 (existing websites) and 23 June 2021 (mobile applications). The developer teams will strive for accessibility of their implementations and consult with accessibility experts or partners where appropriate. As mentioned before, it has to be noted that a full compliance may be impossible to achieve due to properties of Augmented Reality and, to a lesser extent, also maps. While both provide unique ways of accessing information and support spatial cognition, they come with inherent barriers to people with certain disabilities.
8.4 Sustainability beyond the scope of the project All components and their modules will be developed by a dedicated partner avoiding shared ownership and “orphaned” software. All CO3 components will be available under permissive licenses and be maintained by the original developer teams. Details have been provided in the respective chapters. The integration paradigms permit the operation as a distributed system, i.e., the integration will be achieved on the service level (user experience) provided by independent applications. Integration core services will be enhanced in a way which does not break backward compatibility. This will avoid forks and ensure any set of CO3 applications can be combined with any set of WeGovNow applications contributing to an ever growing ecosystem. In principle, CO3 will also be open to the integration of third party applications. Torino already operates a platform with non CO3 applications originating from WeGovNow. The Paris pilot site considers the integration of third party applications (see: Integration of non CO3 components during CO3). Deep integration between components will be accomplished with a focus on broad applicability avoiding unnecessary dependencies. CO3 will pursue a modular and flexible adoption to the envisaged use cases as well as sustainability beyond the scope of the project.
67
CO3 Project D2.1
Annexes
CO3 Unified User Management and Integration Framework
Integration Manual and Step-by-Step Guide
(as of 18.12.2019)
CO3 - Structure of Events - for OnToMap Logger
(as of 18.12.2019)
Unified CO3 Platform Feature List
(as of 18.12.2019)
Contributor License Agreements used by individual partners
(as far as already available)
Fact sheets on software components, all dependencies and licensing
(as far as already available)
68
CO3: Digital Disruptive Technologies to Co-create, Co-produce and Co-manage Open Public Services along with Citizens
CO3 Unified User Management and Integration Framework
INTEGRATION MANUAL AND STEP BY STEP GUIDE
© 2019 FlexiGuided GmbH, Berlin Andreas Nitsche and Björn Swierczek
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement number 822615.
CO3UUM Manual
Test platform for integration (CO3 specific) 4
CO3UUM API endpoints (CO3 specific) 4
Usage of scopes / screen name 5
Handling of updated user related data / user's email addresses 6
Sustainability, unregistered third-party clients and the future 6
Scopes vs. user privileges 7
List of scopes 7
X.509 certificate for client identification 9
Integration Checklist 9
Navigation bar: display of (currently) active applications 11
Navigation bar: Enhanced login button (redirect to calling application) 11
Examples of /api/1/navigation call 12
Navigation bar: user specific menu bar for logged in users 12
CORS request to check if a user is logged in (without actually triggering a login) 12
Application Discovery 16
Unified user management (flow) 17
Role accounts 22
2
CO3UUM Manual
For information regarding OAuth2 we recommend the following specification documents:
● RFC 6749: "The OAuth 2.0 Authorization Framework” ● RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage"
3
CO3UUM Manual
Test platform for integration (CO3 specific) LiquidFeedback with the CO3 server extension is available at
https://co3.liquidfeedback.com/ The base URL of the API is
https://co3.liquidfeedback.com//api/1/ All partners received invite codes for self-registration of user accounts. More codes are available on request. CO3UUM API endpoints (CO3 specific) The CO3UUM endpoints for OAuth2 and the integration framework are available at the following URLs:
https://co3.liquidfeedback.com/api/1/authorization https://co3-cert.liquidfeedback.com/api/1/token ***
https://co3.liquidfeedback.com/api/1/validate https://co3.liquidfeedback.com/api/1/navigation * https://co3.liquidfeedback.com/api/1/style ** https://co3.liquidfeedback.com/api/1/client **
* The content provided by this endpoint is an example and subject to further improvements. ** These endpoints are subject to change. *** Due to limitations in TLS and the way web browsers handle client certificate requests, we need a different hostname for client requests providing a client certificate. For requests made by a client application providing a client certificate please always use the following alternative API base URL:
https://co3-cert.liquidfeedback.com/api/1/
4
CO3UUM Manual
Usage of scopes / screen name When acting as CO3UUM client without data exchange with other CO3 applications, you will only need to request the "authentication" or the "identification" scope to be able to identify the user. These scopes allow to retrieve some user related information (i.e. numerical ID, identification string, screen name) to identify the user. When using the "authentication" or the "identification" scope, the response of the /api/1/token endpoint can optionally include an additional data structure providing member information. To request this optional "member" data structure, you need to set the parameter "include_member" to 1 or "true". Using the "identification" scope with the parameter "include_member" set to true, the response to the /api/1/token endpoint could look like as follows: { "access_token": "UFYPzKrz7JHIKATI", "expires_in": 3600, "refresh_token": "5QM8OL7AbdabXusG", "token_type": "bearer", "member_id": 123, "member": { "id": 123, "name": "Johnny", "identification": "John Doe" } } The field "id" of the "member" object contains the static numerical ID of the user (equal to "member_id", i.e. redundant), the field "name" contains the screen name chosen by the user, the field "identification" contains the identification string set by the authority which identified the user as unique and eligible to use the CO3 application. In future there may be more fields according to the upcoming specification of the /api/1/member endpoint of LiquidFeedback. The parameter "include_member" can also be used at the /api/1/validate and the /api/1/info endpoints. When acting as CO3 application using user related data or services of other CO3 applications, you will need to request the appropriate scopes from CO3UUM for the types of actions you want to perform with other CO3 applications (e.g. if you want to post new content to other applications, request the scope "post"; if you want to rate content in other applications request the scope "rate"; ...).
5
CO3UUM Manual
When acting as CO3 resource server (i.e. when offering user related data or services to other CO3) you need to check (via the /api/1/validate endpoint) the scopes of the access token you received from the requesting application (e.g. if another application tries to post content for a user, check for scope "post"; if another application tries to rate content, check for the scope "rate"). Handling of updated user related data / user's email addresses When a CO3 application wants to send notification emails to users, it is not adequate to retrieve the email address only once from CO3UUM as the notification email can be changed by the user at any time. Such a change needs to be reflected by all applications using this email address. Therefore an application needs to retrieve the current notification email address *directly* before using it, in fact again before every usage. For that purpose, the newly introduced API endpoint GET /api/1/notify_email can be used (using an access token with the "notify_email" scope). To be able to retrieve the email address while the user is not currently logged in, it will be necessary to request the "notify_email_detached" scope when identifying the user and to store the received refresh token permanently. The suffix "_detached" requests a scope for detached usage, i.e. for usage even after the user logs out. Please note, when exchanging a refresh token for an access token after the user has been logged out, you must explicitly request the "*_detached" scope(s) you need, e.g. "notify_email_detached" using the scope parameter of the /api/1/token endpoint. Similar situations can occur related to other member properties stored in one application but used in another one, e.g. the screen name. But these seem not to be as critical as to avoid using an outdated email address. Such properties could be cached for a limited time before retrieving them again from the application storing this property. Sustainability, unregistered third-party clients and the future Following these rules, even a complete new (non-registered, third-party) application can easily make use of the CO3 infrastructure. The application can request certain scopes from CO3UUM (which can be granted or declined by the user) and use the appropriate services of all other CO3 applications. Using the upcoming application and service discovery, this is also possible vice versa.
6
CO3UUM Manual
Scopes vs. user privileges NB: The scope does NOT grant a privilege to a user, it just means an application can trigger an action within the scope *if* the user is authorized to perform the action. Example voting: an application needs the scope "vote" to cast a vote on behalf of the user but casting a vote will only work if the user has the necessary voting privileges. You can think of this as a matrix of scopes and user privileges or (alternatively) as a logical AND conjunction. Scopes control that an application does not misuse user privileges: while the trusted CO3 applications can request certain scopes without user interaction, a non-trusted third party application/client would trigger a request for a user confirmation “Do you want to allow application X to cast votes on your behalf? [yes, one time / yes, permanently]” (compare to permissions for third party Twitter/Facebook clients and Android permissions). The access token which is bound to a specific user is only used to authorize an action on behalf of the user. Whether a user is allowed to perform a certain action must be checked nonetheless. This is out of scope of CO3UUM but part of the “logic” of each application. Which means that CO3UUM authorises that indeed the one who calls is the right person BUT it's on every core component side to handle the "business logic" such as: (allow user to vote only once, mark an issue as solved, etc). List of scopes
● authentication Authenticate the current user by reading its
○ unique static ID (id) ○ current screen name (name)
● identification
Identify the current user by reading its unique ident string (identification). Automatically implies scope "authentication".
● notify_email Read the notification email address of the current user (notify_email)
● read_contents Read any user generated content (w/o authorship, ratings and votes)
● read_authors Read the author names of user generated content (author's static ID and screen name)
7
CO3UUM Manual
● read_ratings Read rating scores by other users
● read_identities Read the identities of other users (identification)
● read_profiles Read the profiles of other users (e.g. phone number, self-description)
● post Post new content
● rate Rate user generated content (e.g. thumbs up/down, "+1", support an initiative, rate a suggestion)
● vote Finally vote for/against user generated content in a decision (i.e. vote on an issue)
● profile Read profile data of current user (e.g. phone number, self-description, ...)
● settings Read current user's settings (e.g. notification settings, display contrast, ...)
● update_name Modify user's screen name (name)
● update_notify_email Modify user's notification email address (notify_email)
● update_profile Modify profile data (e.g. phone number, self-description, ...)
● update_settings Modify user settings (e.g. notification settings, display contrast, ...)
Any of these scopes can be suffixed with "_detached" to request the scope for usage without the need for the user to be logged in. This should only be used when it is really needed.
8
CO3UUM Manual
X.509 certificate for client identification To create a trustworthy relationship between applications using CO3UUM and the central CO3UUM component, we will use X.509 certificates. Therefor, any official CO3 client is required to provide a valid X.509 certificate with each request made to the central CO3UUM service. For this purpose we kindly ask all technical partners to provide X.509 certificate signing requests to be signed by the CO3UUM Certificate Authority. For more information on X.509 certificates and signing requests, please refer to the documentation of your preferred TLS software such as LibreSSL or OpenSSL. Also see point 6 of the Integration Checklist. Integration Checklist We will support all technical partners during CO3UUM integration. We defined a number of steps we like to accomplish with every technical partner. In the following list, the term "client application" refers to the application to be integrated with CO3UUM.
1. Availability of application via IPv4 The client application is available via a defined URL using IPv4.
2. Availability of application via IPv6. The client application is also available using IPv6.
3. Serving via HTTPS The client application service is encrypted via HTTPS.
4. Publicly trusted X.509 certificate for end users The client application server provides a publicly trusted X.509 certificate (see 3).
5. OAuth2 redirection endpoint defined The URL of the OAuth2 redirection endpoint of the client application has been determined and submitted to LiquidFeedback (FlexiGuided GmbH).
a. Endpoints need to be pre-registered for security reasons. b. Multiple endpoints are possible (one is the default endpoint). c. The endpoint can be selected by the redirect_uri parameter. d. If redirect_uri is omitted the default endpoint will be used.
6. Certificate signing request for CO3UUM
A private key for accessing the CO3UUM API has been created. A
9
CO3UUM Manual
corresponding certificate signing request (CSR) has been submitted to LiquidFeedback (FlexiGuided GmbH).
a. Either co-signed X.509 end user certificate or a new certificate (only for communication between the application and CO3UUM).
b. Example for creating a CSR: openssl req -out co3.example.com.csr -new -newkey rsa:2048 -nodes -keyout co3.example.com.key
7. Certificate signed by CO3UUM Certificate Authority A signed certificate for the client application has been sent back to the technical partner.
8. Successful X.509 secured connection The client application has successfully established a secure connection with the CO3UUM server, e.g. using LiquidFeedback's /info API endpoint.
9. Authorization endpoint access The client application can redirect an end user to the CO3UUM authorization endpoint.
10. Authorization endpoint error response handling The client application is capable of receiving authorization errors through its OAuth2 endpoint.
11. Authorization endpoint error display The client application is able to display authorization error messages (see 10) to the end user.
12. Successful authorization request and user identification The client application made a successful authorization request, received a CO3UUM access token, and determined the end user ID.
13. Using access token for API calls to other components The client application has successfully performed a LiquidFeedback API call (e.g. to the /info API endpoint) using a previously obtained CO3UUM access token.
14. Accepting access token from other components The client application (acting as resource server) provides at least one API call which accepts a CO3UUM access token for authorization.
15. Access token verification The client application (acting as resource server) is capable of verifying the validity and scope of a CO3UUM access token passed from another component (see 14).
10
CO3UUM Manual
16. Access token verification errors
The client application (acting as resource server) is capable of handling error responses during validation of CO3UUM tokens (see 15).
17. Accepting access tokens as "Authorization" header In conformance with RFC 6750 (Bearer Token Usage), the client application (acting as resource server) accepts CO3UUM access tokens through the HTTP request header field "Authorization".
18. Cross-origin resource sharing (CORS) The client application (acting as resource server) allows cross-origin resource sharing (CORS). See also https://www.w3.org/TR/cors/
19. HTTP Strict Transport Security (HSTS) The client application ensures secure access by using HTTP Strict Transport Security (HSTS) according to RFC 6797.
20. Cross-application navigation The CO3UUM navigation bar has been successfully integrated into the client application.
a. An additional format (RAW HTML instead of JSON) for the navigation endpoint was introduced by request of UniTo.
b. .../api/1/navigation?format=raw_html&access_token=your_access_token
c. see “display of current application” d. see “enhanced login button (redirect to calling application)” e. see “user specific menu bar for logged in users”
Navigation bar: display of (currently) active applications Please add the parameter client_id=<your client id> to your navigation endpoint call. This enables visual highlighting of the navigation bar entry corresponding to your application. Navigation bar: Enhanced login button (redirect to calling application) To make sure the user is redirected to the application from which he/she came from you can add the parameter login_url=<your login_url> to your navigation endpoint call. The URL needs to be set as a link to the page on your site which initiates the OAuth2 login or alternatively you can directly provide the URL of the
11
CO3UUM Manual
/api/1/authorization endpoint including the appropriate client_id, redirect_uri and state. If you cache the result of the navigation endpoint and your login_url is volatile, please set a unique placeholder which can be replaced any time you deliver a page containing the navigation bar. Examples of /api/1/navigation call (without proper encoding to enhance readability) /api/1/navigation?client_id=co3.example.com&login_url=/component/slogin/provider/uwum/auth /api/1/navigation? client_id=co3.example.com &login_url=https://co3.liquidfeedback.com/api/1/authorization? client_id=co3.example.com &redirect_uri= https://co3.example.com/ &state=mysecretstate /api/1/navigation?client_id=co3.example.com&login_url=RANDOMPLACEHOLDER_134jn4hjnf9823r23dd
Navigation bar: user specific menu bar for logged in users Please don't forget to include the access token (parameter access_token) when calling the navigation bar for a logged in user. This way the navigation bar will display the screen name of the user and the link to the (future) user menu. Example: .../api/1/navigation?access_token=your_access_token CORS request to check if a user is logged in (without actually triggering a login) There may be situations where you want to check whether a user is currently logged into CO3 without actually forcing the user's web browser to perform a login if no user was logged in. We evaluated multiple ways to solve this issue (including a "prompt=none" parameter for the /api/1/authorization endpoint, similar to the solution used by OpenID), but unfortunately it turned out that most ways
● are infeasible for 3rd-party clients, ● would lead to unwanted data exposure, ● have a bad response performance, or ● have a high implementational effort, ● or a combination thereof.
12
CO3UUM Manual
We finally found a solution based on a CORS (Cross-Origin Resource Sharing) XMLHttpRequest done by the web browser. This solution works with any registered client but also with any 3rd-party client and prevents unwanted data exposure. However, since the request is done by the user's web browser, the answer is *not* authoritative and must only be used as a hint. A returned member_id MUST still be validated via the regular OAuth2 procedure using the GET /api/1/authorization endpoint! In this case, the authorization endpoint will not show a login window (because the user is already logged in). The call to the new API endpoint POST /api/1/session does not need any parameter (and SHOULD NOT add any request header) but may only be called directly by the web browser of the user and requires the "withCredentials" option of the XMLHttpRequest object to be set to true (see code example below). The result is a JSON object with the member_id attribute set to the static ID of the current user (or zero if there is no logged-in user or if a 3rd-party client is not authorized to obtain the login status): { "member_id": 123 } or { "member_id": null } Example JavaScript code: function checkCO3Session(callback) { var xhr = new XMLHttpRequest(); var url = "https://co3.liquidfeedback.com/api/1/session"; xhr.open("POST", url, true); xhr.withCredentials = true; // sends CO3UUM cookies to CO3UUM (important) xhr.onreadystatechange = function() { if (xhr.readyState == 4) { if (xhr.status == 200) { var r = JSON.parse(xhr.responseText); callback(r.member_id); } else { // some error occured, add error handling callback(undefined); } } } xhr.send(); } checkCO3Session(function(result) {
13
CO3UUM Manual
if (result === undefined) { // note === to distinguish undefined from null window.alert("Error during request") } else if (result) { window.alert("Web browser claims that a user with the following ID is logged in: " + result); } else { window.alert("Web browser claims that no user is logged in."); } }); We encourage you to test this function with several web browsers since the CORS feature might behave differently in regard to browser implementation. For the technical background, we refer to the following document: https://www.w3.org/TR/cors/
14
CO3UUM Manual
Application Discovery
15
CO3UUM Manual
Unified user management (flow)
16
CO3UUM Manual
17
CO3UUM Manual
18
CO3UUM Manual
refresh
19
CO3UUM Manual
20
CO3UUM Manual
Role accounts Whenever a user is acting with a role account on behalf of an organization, the following API endpoints additionally have the field "member_is_role" set to true and include a real_member_id field (set to the member id of the user who switched to the role account) in the result:
● api/1/validate ● api/1/token ● api/1/session ● api/1/info
Please note: For detached sessions (we are not aware that this feature is used in the consortium) the result does not include a real_member_id, but "member_is_role" is set to true.
21
CO3: Digital Disruptive Technologies to Co-create, Co-produce and Co-manage Open Public Services along with Citizens
Structure of Events for OnToMap Logger
INTEGRATION MANUAL AND STEP BY STEP GUIDE
© 2019 FlexiGuided GmbH, Berlin Andreas Nitsche and Björn Swierczek
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement number 822615.
URLS to information about OTM Logger (CO3OTM):
CO3OTM API SPECIFICATIONS: https://dev.co3.ontomap.eu/
JSON schema describing the syntax of event types and of the features: https://dev.co3.ontomap.eu/api/v1/logger/events/schema
JSON schema describing the syntax of the mapping rules (mappings) to be defined in order to integrate a CO3 application with CO3OTM: https://dev.co3.ontomap.eu/api/v1/logger/mappings/schema
OTM ONTOLOGY, for definition of concepts, available at the following URL: https://dev.co3.ontomap.eu/ontology/
In the following rows we report a description of the types of activity currently logged by CO3OTM. New types can be introduces on the basis of the needs of the applications to be integrated in CO3 Platform
Legenda: in the rows below, red fields are mandatory, the other ones are optional
activity type actor timestamp ACA activity_objects references details visibility_details
name of the logged activity CO3-UWUM ID of user who performed the action to be logged
UNIX time stamp in milliseconds. It represents the time of the occurred action
Name of the ACA within which the event has been generated (to be decided whether an external URL is needed to identify the ACA within a pilot)
Array of type either GeoJSON Features or NonGeoObject - see below for the details, by action type
Array of objects structured as follows: {external_url, application, type}; external_url and application are mandatory, type is optional.
Object: It stores all the fields specific for an activity or for an application (details can be used to represent attributes that are not mapped in the OTM ontology)
Useful to manage data hiding or to restore visibility of logged actions in data retrieval API. Array of pairs {external_url, hidden} where hidden is boolean. The external_urls are those of the logged actions for which the visibility status for data retrieval must be changed
object_created
the created objects must be either GeoJSON features with a geometry (e.g., a school, etc.) or non geometric objects
For comments, LF initiatives: this field stores the reference (see above) to the indirect objects of the action. For instance, if a user creates a suggestion to an initiative, a reference to that initiative is included in geo_objects. Otherwise VOID.
object_updated
the updated (geo)objects
For initiatives, suggestions and issues: reference to the indirect objects, as above. Otherwise VOID.
object_removed
the removed (geo)objects
For initiatives, suggestions and issues: reference to the indirect objects, as above. Otherwise VOID.
interest_addedVOID reference to LF issue
interest_removedVOID reference to LF issue
support_added VOID reference to the initiative
support_removed VOID reference to the initiative
initiator_added VOID reference to the initiative
initiator_removed VOID reference to the initiative
suggestion_rated VOID reference to the suggestion
the rating could be stored here
delegation_setVOID reference to the
OU/subject area/issuedetails about delegation (delegatee, scope etc.)
delegation_changed VOID reference to the OU/subject area/issue
details about delegation (delegatee, scope etc.)
delegation_removed VOID reference to the OU/subject area/issue
details about delegation (delegatee, scope etc.)
issue_voted_on VOID reference to the issue votings per initiativeaccount_registered VOID VOID details about the user actionscreen_name_changed VOID VOID details about the user action
profile_updated VOID VOID details about the user actionavatar_changed VOID VOID details about the user actioncontact_published VOID VOID details about the user actioncontact_unpublished VOID VOID details about the user actionissue_timeline_requested VOID reference to issueissue_status_updated VOID reference to LF issue details about the status changecontribution_addedcontribution_updatedcontribution_removedsubscription_addedsubscription_removed
token_transferred
type is not optional: it must take the values "from" and "to"
the amount of coins must be specified here
token_mintedthe amount of coins must be specified here
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
3 Self registration The user registers an account providing data specified by the pilot site. x E B L x x x ready for use
4 Login
The user logs into the platform using credentials. Dependency: The components need to support the CO3 Single Sign-On (SSO).
x x x x x x E B L x x x x x ready for use
5 LogoutThe user logs out of the platform. Dependency: The components need to support the CO3 Single Sign-On (SSO).
x x x x x x E B L x x x x x ready for use
6 User administration The user can see user registrations, edit priviliges/units of a user, lock users. x I - B L x x x x ready for use
66 Recovery of login name User can recover all login names assiated to a (verified) email address x x x x x x E B L ready for use
67 Password recoveryUsers can request a password reset link to the verified email address by entering their login name
x x x x x x E B L ready for use
7 AR/CO3 App uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E - L x x x x x x accepted
8 Blockchain uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E B x L x x x x x x accepted
71Blockchain uses CO3UUM as a key storage
The user can store the private key in CO3UUM. This would enable a key recovery mechanism.
x x x x x x L x accepted
9 FirstLife uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E B L x x x x x x ready for use
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
10 LiquidFeedback uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E B L x x x x x x ready for use
11 RenKan uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E B x L - x x suggested
12 Hypothes.is uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E B x L - x x suggested
13 MineCraft uses Single Sign-On
The user is logged into all platform components at once and can switch without a new login. This also enables cross component use such as providing functionality from other components.
x E B x L - x suggested
14 Blockchain sendsevents to OntoMap
Components send an event stream to OntoMap. OntoMap provides semantic interoperability and serves as a cross platform catalog. This also fascilitates the AR view and common map views.
x L x x x x x x accepted
15 FirstLife sends events to OntoMap
Components send an event stream to OntoMap. OntoMap provides semantic interoperability and serves as a cross platform catalog. This also fascilitates the AR view and common map views.
x L x x x x x x ready for use
16 LiquidFeedback sends events to OntoMap
Components send an event stream to OntoMap. OntoMap provides semantic interoperability and serves as a cross platform catalog. This also fascilitates the AR view and common map views.
x L x x x x x x ready for use
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
39 Authority defined groups
The user administration can assign membership in authority defined groups. The feature is provided by CO3UUM using the unit concept of LiquidFeedback. By unit assignment, registered users receive voting rights and/or other privileges.
x x I E B L x x x x x ready for use
40 Global management of the groups
Groups defined by unit assignment shall be available throughout the entire platform, i.e. in all applications.
x x x x x U L x x x x suggested
41 Self-defining groups
Users can join and leave self-defining groups by using the groups feature of FirstLife. The feature will be rolled out with the new version of FistLife.
x x x x x E B L x x ? in progress
68 Mirror FL groups to LF units
Self-defining groups (41) are mirrored to authority defined groups (39) feeding into the global authorization scheme (40).Self-defined groups have their own place for voting and in general can use features requiring privileges such as voting rights.
x E B x L suggested
47Fine graded group based authorization system
Access rights can be assigned for defined resources and kind of access, i.e. read or write, based on group membership. From: PAR1: "Consider two ways to access to the contents that are displayed on the map: (1) is public and (2) are group-resources entities. Group-resources entities are visible on the map, but the user has to join the group. Access conditions/criteria to the groups may be different: open groups, semi-open groups (acceptation of the new member by the admins or at least by 2 members of the group) and private group (invitation can be sent only by admins)."
x E B - x assessment
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
54 Group-filters
The view over the entities/events can be modified by using group-filters that are visible on the screen (ex. contributive clinic group filter = the user can see only contributive clinic entities);
x x x x x ? E B x x x x x assessment
17 Create ACAsThe user can create an ACAsub feature: Define area boundaries.→ 18 Define area boundaries
? ? ? ? x - B x x x split
18 Define area boundaries Geofence an area with a polygon(no bounding box approach). ? ? ? ? x I - B L x x x x accepted
22Restrict mapping in an area/setup protected mapping
Restrict the mapping (creation of FirstLife objects and tagging) inside the boundaries of an area defined by 18. The PA assigns the right to map in area #n to unit #m.
x I - B L x x accepted
23 Presence mapping Creating FirstLife objects and marking them with logos is restricted to physical presence. x x x x P - L x x x discussion
24 Protected geofenced mapping in presence
Creating FirstLife objects and marking them with logos in geofenced area (18/22) is only possible for members of a specified unit AND in physical presence.
x x x x I/U P - L x x discussion
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
55 Tag Real-life objects with AR
The user opens the AR view on mobile app, scan a real-life object and is able to add: - Tag- Multimedia content: picture, video,- 3D objects→ 23 and 24
x x x x x ? P - L x x accepted
56 Geolocate a real-life object
The real-life object is automatically geolocated (lat-long) → 23 and 24
x x x x x ? P - L x x accepted
58 Retrieve Real-life object with AR
The user can see a tag of a real-life object on the map and when is near enough (10 meters) the AR view is enabled to interact with this object and retrieve the multimedia content attached to it.
x x x x x ? P - L x accepted
57 Attach a picture to a real-life object
The user can attach a picture of a real-life object after scaning it to guide future users to find it- Like a hint. using → 52 Assign photo to FirstLife objects
x x x x x ? P - L x x accepted
19 Display ACAs
The user sees all ACAs on a map.(several sub features listed)→ 33 for App Dashboard→ 34 for Landing Page and AreaViewer→ 59 for Dashboard Activity Log→ 60 for Activity Log on Landing Page
x x x x x x E B x x x x x x split
33Dashboard:FL objects and LF deliberations in AR App
Display and link to FirstLife objects and indicate related ongoing deliberations in LiquidFeedback. → 59 Dashboard Activity Log
x x x x x x E - L x x x x accepted
34
Landing page:FL objects and LF deliberations on area viewer and in landing page
Display and link to FirstLife objects and indicate related ongoing deliberations in LiquidFeedback
x x x x x x - B L x x x x ready for use
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
61 Activity Log dataThe OntoMap Event Logger provides (user specific) activity logs→ 14-16 for data sources
x - - L x x x x x ready for use
59 Dashboard Activity Log
A dashboard for visualizing the tagged entities, the number of them, the kind of object tagged (material, monument, place, …) in order to exploit and filter these data for a better and more specific use of the tool. Also to visualize interactions with entities from others→ 33 for App Dashboard
x x x x x ? E - L x x x x discussion
60 Activity Log on Landing Page
The Landing Page shows events (interactions with all components) based on the data provided by OntoMap.→ 34 forLanding Page and AreaViewer
x x x x x - B L x x x x x ready for use
35 FirstLife embedding in AR
FirstLife to be displayed inside der AR App as link target for the "FL objects and LF deliberations in AR App" feature
x x x x x x E - L x x accepted
36 LiquidFeedback embedding in AR
LiquidFeedback to be displayed inside der AR App as link target for the "FL objects and LF deliberations in AR App" feature
x x x x x x E - L x x accepted
53The user can choose the range of its localization (1km->20km = +/–);
The user will be able to zoom in and zoom out according to his-her preference. x x x x x x ? E L x x x accepted
37 QR Codes ReaderQR code integration mechanism to make transactions quicker and easier by beneficiaries
x E - L x accepted
38 QR Codes GeneratorQR code generator mechanism to create QR codes to trigger specific actions in the mobile app
B L x accepted
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
42Easy switch between AR (Camera) view and Map view
UX related request for the CO3 App:Users can easily switch between Camera and Map views
x x x x x x E - L x discussion
20 Presence indicator
AR App provides information to other applications if a user is currently within the boundaries of an ACA to allow restricting actions to physical presence where required.
E L ? ? discussion
43 No access to AR and Map views for visitors
CO3 App (AR and Map views): Geolocalized entities/publications/events/… are accessible to the user only when logged in.
x E - L x x rejected
44 No access to FirstLife content for visitors
FirstLife: Geolocalized entities/publications/events/… are accessible to the user only when logged in.
x - B L x x rejected
21 Create wallet The user can create a wallet for storing tokens. x E L x accepted
31 Voting weight based on blockchain tokens
The user votes with a voting weight determined by available tokens.Sub features to be specified by the involved partners. → 69 Creation of voting tokens→ 70 Consumption of voting tokens
T E B x x x split
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
69 Creation of voting tokens
Voting tokens can be created in the blockchain (e.g. by converting other tokens). These tokens can be transferred to LF on user request. Each voting token represents a voting weight of 1 for a single voting. Voting tokens can only be consumed by LF.
x T E B L x accepted
70 Consumption of voting tokens
Voting tokens created by the blockchain can be assigned to a specific vote a user casts in LF. Every voting token can only be used once for voting on a single issue and represents a voting weight of 1. The consumption of each token is recorded in LF.
x T E B L x accepted
52 Assign photo to FirstLife objects
The user can upload a photo of a FirstLife object. x x x x x E B L x x x ready for use
25 Deliberation and voting on FirstLife objects
Link LiquidFeedback initiatives to FirstLife objects and use LF functionality (see sub features).
x x x x p U E B x L x x accepted
26 Start initiativeThe user starts a deliberation and voting process on an issue or adds an alternative to existing initiatives.
x x x x x U E B L x x ready for use
27 Support initiave The user supports an initiative. x x x x x U E B L x x ready for use28 Add suggestion The user adds a suggestion to an initiative. x x x x x U E B L x x ready for use29 Assess suggestion The user assesses a suggestion. x x x x x U E B L x x ready for use
30 Preferential voting The users votes on an issue (set of alternatives) by preferential voting. x x x x U E B L x x ready for use
32View initiativesView suggestionsView voting results
The user can see initiatives, suggestions and voting results. x x x x x x du E B L x x x x ready for use
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
45No access to LiquidFeedback content for visitors
LiquidFeedback: Geolocalized entities/publications/events/… are accessible to the user only when logged in.
x - B L x x rejected
46No access to objects on Landing page map and common map
Landing page and common map: Geolocalized entities/publications/events/… are only accessible for the logged in users.
x - B L x x rejected
48 API call for Renkan document creation
RenKan provides an API call to allow the automated creation of ReKan documents x E B L - x x suggested
49 API call for Hypothes.is document creation
Hypothes.is provides an API call to allow the automated creation of Hypothes.is documents
x E B L - x x suggested
50Renkan document creation and link in LiquidFeedback issues
LiquidFeedback automatically creates and links to RenKan document upon issue creation
x E B L - x x suggested
51Hypothes.is document creation and link in LiquidFeedback issues
LiquidFeedback automatically creates and links to Hypothes.is document upon issue creation
x E B L - x x suggested
CO3 Platform Feature List CO3 user roles Components [1] Required for use case Implementation
Featur
e
Descri
ption
Anyon
e (pu
blic a
cces
s) [2]
Approp
riator
[3]
Contrib
utor [4
]
Facilit
ator [5
]
Partne
r [6]
Officer
(PA or
syste
m opera
tor) [7
]
Tech a
dmin
(no co
ntent)
[8]
Enabli
ng In
frastr
uctur
e [9]
Indiv.
privil
ege,
Unit, T
oken
[10]
App (E
veryw
here,
Pres
ence
) [11]
Browse
r (on
ly with
E or
- ) [1
2]
AR app
Blockc
hain
FirstLi
fe (w
/ LP/A
V/IM)
Liquid
Feedb
ack
OntoMap
CO3UUM
LINKS de
velop
ment
IRI d
evelo
pmen
t
Propos
al
ATH1 Groc
eries
on ho
ld
ATH2 Map
ping c
omm.nd
s
PAR1 Con
tributi
ve C
linic
PAR2 Rcy
clg, B
IM, U
rbnMod
Status
[13]
62 Newsletter (NL) Officers (PA or system operator) can send newsletters to registered users x x B L ready for use
63 Schedule NLs Newsletter can be scheduled by providing a date and time x x B L ready for use
64 Target NLs to groups (units)
Officers (PA or system operator) can choose which units shall receive a newsletter (=members of which authority defined groups)
x x B L ready for use
65 Override communication preferences for NLs
Officers (PA or system operator) can override the user's communication preference and enforce the deliverable of newsletters (feature for urgent communication)
x x B L ready for use
[1] * L: Lead* x: involved/supporting
[2] Anyone: This is what everyone can see without logging in, i.e. available to the public, sometimes referred to as "temporary user" or "touristic view".
[3] LINKS: "APPROPRIATOR: Registered user that and acts as a commoner directly in the ACA demanding or using shared resources (tangible and intangible) made available in the phygital common.They can be residents or not.To act as an appropriator it is required to be in the ACA (proof of presence)."
[4] LINKS: "CONTRIBUTOR: Registered user that acts as a commoner directly in the ACA providing “core” resources (tangible and intangible) made available in the phygital common."
[5] LINKS: "FACILITATOR: Registered user that can be identified by commoners/within the common, (to facilitate operations and exchanges.They can be identified among contributors (bottom-up process) if a form of inner organization is required by commoners."
[6] LINKS: "PARTNER: Registered user that act as a stakeholder and that can offer or enter in partnership with the commoners (with coupons, gadgets). They can also provide auxiliary support to operations and resources (tangible or intangible)."
[7] Officer: Authorized users of the public administration/system operating organization. These users will most likely use their personal accounts to switch into a role account with the respective access rights.p: only parts of the sub features
[8] Tech Admins don't handle content data and should not appear in the workflow of any use case. They are responsible for the operation and "system health". Their tasks include* (security) updates* monitoring* availability* intrusion detection
[9] Necessary background functionality used through functionality listed elsewhere.
[10] Explains how access rights are provided* I: individual privilege assignment* U: unit assignment (a user can be assigned to several units)* I/U: both approaches are feasible, to be discussed* du: access is not restricted to unit assignment but the unit assignments determine what is visible by default* T: token
[11] E: EverywhereP: Presence required-: not available in the App
[11] E: EverywhereP: Presence required-: not available in the App
[12] * B: Access by Browser only with E or - for the App
[13] * Suggestedfeature has been suggested but needs further discussion* Assessmentcomplex and/or vague idea which needs to be assessed, conceptualised and split into basic functions assigned to specific developer teams* Discussionfeature is being discussed by the affected partners* Rejectedfeature will not be realised or replaced by an alternative* Splitfeature has been split into sub features/parts/modules* Acceptedfeature is sufficiently specified, accepted by the responsible partners and likely to be realised* In progressimplementation ongoing* Ready for usefeature available in principle, minor adjustments or configuration may be necessary
Public Software Group e. V., Berlin, Germany (“Public Software Group”)Software Grant and Corporate Contributor License Agreement v1.0 (“Agreement”)
This document was derived from the “Contributor License Agreements” as published on the Website of the Apache Software Foundation and contains modifications by the Public Software Group. The following license applies to this document:
Copyright 2009 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the “License”);you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Thank you for your interest in contributing to OpenSource projects of the Public Software Group. In order to clarify the intellectual property license granted with Contributions from any person or entity, the Public Software Group must have a Contributor License Agreement (“CLA”) on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Public Software Group and users of its software; it does not change your rights to use your own Contributions for any other purpose. This version of the Agreement allows an entity (the "Corporation") to submit Contributions to the Public Software Group, to authorize Contributions submitted by its designated employees to the Public Software Group, and to grant copyright and patent licenses thereto. If you have not already done so, please complete and send an original signed Agreement to the
Public Software Group e. V., Johannisstr. 12, 10117 Berlin, Germany.
Please read this document carefully before signing and keep a copy for your records.
Name ofCorporation: __________________________________
__________________________________
Address ofCorporation: __________________________________
__________________________________
__________________________________
Country: __________________________________
Point ofContact: ____________________________________
____________________________________
Telephone: ____________________________________
Facsimile: ____________________________________
E-Mail: ____________________________________
Name ofSignatory: ____________________________________
You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Public Software Group. In return, the Public Software Group shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its bylaws in effect at the time of the Contribution. Except for the license granted herein to the Public Software Group and recipients of software distributed by the Public Software Group, You reserve all right, title, and interest in and to Your Contributions.
Page 1 of 3 Date: _________________________ Please sign: _________________________
1. Definitions. “You” (or “Your”) shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with the Public Software Group. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. “Contribution” shall mean the code, documentation or other original works of authorship expressly identified in Schedule B, as well as any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Public Software Group for inclusion in, or documentation of, any of the products owned or managed by the Public Software Group (the “Work”). For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Public Software Group or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Public Software Group for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Contribution.”
2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Public Software Group and to recipients of software distributed by the Public Software Group a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to the Public Software Group and to recipients of software distributed by the Public Software Group a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
4. You represent that You are legally entitled to grant the above license. You represent further that each employee of the Corporation designated on Schedule A below (or in a subsequent written modification to that Schedule) is authorized to submit Contributions on behalf of the Corporation.
5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others).
6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
7. Should You wish to submit work that is not Your original creation, You may submit it to the Public Software Group separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as “Submitted on behalf of a third-party: [named here]”.
8. It is your responsibility to notify the Public Software Group when any change is required to the list of designated employees authorized to submit Contributions on behalf of the Corporation, or to the Corporation's Point of Contact with the Public Software Group.
Page 2 of 3 Date: _________________________ Please sign: _________________________
Schedule A:
Initial list of designated employees. NB: authorization is not tied to particular Contributions.
Schedule B:
Identification of optional concurrent software grant.Would be left blank or omitted if there is no concurrent software grant.
Page 3 of 3 Date: _________________________ Please sign: _________________________
Public Software Group e. V., Berlin, Germany (“Public Software Group”)Individual Contributor License Agreement v1.0 (“Agreement”)
This document was derived from the “Contributor License Agreements” as published on the Website of the Apache Software Foundation and contains modifications by the Public Software Group. The following license applies to this document:
Copyright 2009 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the “License”);you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Thank you for your interest in contributing to OpenSource projects of the Public Software Group. In order to clarify the intellectual property license granted with Contributions from any person or entity, the Public Software Group must have a Contributor License Agreement (“CLA”) on file that has been signed by each Contributor, indicating agreement to the license terms below. This license is for your protection as a Contributor as well as the protection of the Public Software Group and users of its software; it does not change your rights to use your own Contributions for any other purpose. If you have not already done so, please complete and send an original signed Agreement to the
Public Software Group e. V., Johannisstr. 12, 10117 Berlin, Germany.
Please read this document carefully before signing and keep a copy for your records.
Full name: ____________________________________
____________________________________
PostalAddress: ____________________________________
____________________________________
____________________________________
Country: ____________________________________
Telephone: ____________________________________
Facsimile: ____________________________________
E-Mail: ____________________________________
You accept and agree to the following terms and conditions for Your present and future Contributions submitted to the Public Software Group. In return, the Public Software Group shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its bylaws in effect at the time of the Contribution. Except for the license granted herein to the Public Software Group and recipients of software distributed by the Public Software Group, You reserve all right, title, and interest in and to Your Contributions.
Page 1 of 2 Date: _________________________ Please sign: _________________________
1. Definitions. “You” (or “Your”) shall mean the copyright owner or legal entity authorized by the copyright owner that is making this Agreement with the Public Software Group. For legal entities, the entity making a Contribution and all other entities that control, are controlled by, or are under common control with that entity are considered to be a single Contributor. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. “Contribution” shall mean any original work of authorship, including any modifications or additions to an existing work, that is intentionally submitted by You to the Public Software Group for inclusion in, or documentation of, any of the products owned or managed by the Public Software Group (the “Work”). For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Public Software Group or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Public Software Group for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by You as “Not a Contribution.”
2. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Public Software Group and to recipients of software distributed by the Public Software Group a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
3. Grant of Patent License. Subject to the terms and conditions of this Agreement, You hereby grant to the Public Software Group and to recipients of software distributed by the Public Software Group a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by You that are necessarily infringed by Your Contribution(s) alone or by combination of Your Contribution(s) with the Work to which such Contribution(s) was submitted. If any entity institutes patent litigation against You or any other entity (including a cross-claim or counterclaim in a lawsuit) alleging that your Contribution, or the Work to which you have contributed, constitutes direct or contributory patent infringement, then any patent licenses granted to that entity under this Agreement for that Contribution or Work shall terminate as of the date such litigation is filed.
4. You represent that You are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Public Software Group, or that your employer has executed a separate Corporate CLA with the Public Software Group.
5. You represent that each of Your Contributions is Your original creation (see section 7 for submissions on behalf of others). You represent that Your Contribution submissions include complete details of any third-party license or other restriction (including, but not limited to, related patents and trademarks) of which you are personally aware and which are associated with any part of Your Contributions.
6. You are not expected to provide support for Your Contributions, except to the extent You desire to provide support. You may provide support for free, for a fee, or not at all. Unless required by applicable law or agreed to in writing, You provide Your Contributions on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
7. Should You wish to submit work that is not Your original creation, You may submit it to the Public Software Group separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as “Submitted on behalf of a third-party: [named here]”.
8. You agree to notify the Public Software Group of any facts or circumstances of which you become aware that would make these representations inaccurate in any respect.
Page 2 of 2 Date: _________________________ Please sign: _________________________
Application name: LiquidFeedback
Description: LiquidFeedback is an open-source software, powering internet platforms for proposition development and decision making. Additionally, LiquidFeedback provides single-sign-on and central user management.
Download: https://www.public-software-group.org/liquid_feedback
Web: https://liquidfeedback.org/
Primary technical contact: Björn Swierczek <[email protected]>
Information as of: 2019-01-18
Components shipped with application
Name Description Publisher License URL (open source) / conditions
LiquidFeedback Core
Database application
Public Software Group MIT/X11 (permissive) https://www.public-software-group.org/liquid_feedback_core
LiquidFeedback Frontend
Frontend Public Software Group MIT/X11 (permissive) https://www.public-software-group.org/liquid_feedback
Material Design Lite
Design library Google Apache 2.0 (permissive) https://getmdl.io/started/index.html#download
Material icons Icon library Google Apache 2.0 (permissive) https://github.com/google/material-design-icons
Roboto Font Google Apache 2.0 (permissive) https://fonts.google.com/specimen/Roboto
Voog wysihtml WYSIWYG editor
Edicy LLC MIT/X11 (permissive) https://github.com/Voog/wysihtml
Run-time dependencies
Name Description Publisher License URL (open source) / conditions
PostgreSQL Database The PostgreSQL Global Development Group
BSD-style (permissive) https://www.postgresql.org/download/
PL/pgSQL Programming language
The PostgreSQL Global Development Group
BSD-style (permissive) https://www.postgresql.org/download/
Lua Programming language
Pontifical Catholic University of Rio de Janeiro
MIT/X11 (permissive) https://www.lua.org/download.html
WebMCP Web application framework
Public Software Group MIT/X11 (permissive) https://www.public-software-group.org/webmcp
Moonbridge Network/Web server
Public Software Group MIT/X11 (permissive) https://www.public-software-group.org/moonbridge
FreeBSD also runs on Linux
Operating systems
The FreeBSD Foundation BSD (permissive) GPL (protective)
https://www.freebsd.org/releases/
libbsd only on Linux
Libraries freedesktop.org LLC various for different components: MIT/X11 (permissive) BSD-style (permissive) Beerware (permissive)
https://libbsd.freedesktop.org/releases/
pgLatLon Geospatial library
Public Software Group MIT/X11 (permissive) https://www.public-software-group.org/pgLatLon
pgConflux Database index for feeds
Public Software Group MIT/X11 (permissive) https://www.public-software-group.org/pgConflux
ImageMagick or Graphics Magic or similar
Image resizing utility
ImageMagick Studio LLC GraphicsMagick Group various choices
Apache 2.0 (permissive) MIT/X11 (permissive) various choices
https://www.imagemagick.org/script/download.php http://www.graphicsmagick.org/download.html
sassc Stylesheet processor
Sass Open Source Foundation
MIT/X11 (permissive) https://github.com/sass/sassc
libsass Stylesheet processor library
Sass Open Source Foundation
MIT/X11 (permissive) https://github.com/sass/libsass
Built-time dependencies
Name Description Publisher License URL (open source) / conditions
C compiler Build dependencies
various choices various choices (permissive and others)
various