Development bucket list

To guide the development of products and services of PublicSpaces, we have in place both a development ‘guide’ and a backlog of functionalities and components that we expect to be built.

Underlying our working methods is the idea that our development activities should be as open and flexible as possible. This is both born from a need to be efficient and make good use of available resources, and from a more principled view that in the public and open source network that PublicSpaces aims to be, everybody should be able to participate and contribute.

In practice, this means:

  • parties in the coalition that hope to contribute to the development of components, need to coordinate their efforts. This ensures that work is not duplicated, and that components fit together on the same underlying ‘architecture’. Federation on the application and protocol level should be applied.
  • Within these bounds, parties are free to develop any type of component or functionality that they need on any given moment. Provided that development conforms to PublicSpaces standards as set down in a development ‘guide’, (that will be determined shortly), these components carry a PublicSpaces label.
  • It is conceivable that parties will develop at different speeds, each according to their needs and capacity, and work in different collaborations both within and without the coalition. This is actually a good thing, since this agility and openness contributes to the strength of the PublicSpaces network
  • Finally, this is also in line with our ambition to engage the open source community in the development of components. We envision a lively development ‘ecosystem’ of individuals and organizations that collaborate, discuss and promote the ideals of PublicSpaces.

Guidelines for components

We envision seven categories of functionalities to eventually be a part of the PublicSpaces ecosystem of components. Every component in each category will comply with a number of criteria set for that category.

  1. Data and content management
    1. Provenance of data is defined through: 
      1. application through which it is created or uploaded
      2. list of known attributes of creator (name, reputation, email, home town)
    2. Data is signed by creator and verifiably original (creator can remain anonymous)
    3. Data is either in the public domain or owned by an account (entity) with the right credentials
    4. Derived works (mashups, spoofs etc) are possible provided that provenance history is always complete (as in 1A and 1B)
    5. Data is accessible through a uniform URL schema, as for instance provided by Solid
    6. Data is available from everywhere in the PublicSpaces ecosystem, subject to use restrictions
    7. Conditions of (re-)use are clearly described (possibly enforced) through attribute-based credentials
    8. Storage location, technology and availability may vary (file server, distributed system or other).
    9. Facility for transcoding and translation of content
    10. Play-out functionality
  2. Authentication, verification, authorization (login, sign-on)
    Any implementation should support ‘zero knowledge proof’ (which means attributes can be proven to be true without disclosing them). It should also support verifiable claims and stored entitlements. Furthermore, it should adhere to the full ‘privacy by design’ ethos. Required functionality:
    1. Lurking (participation without registration, login or sign-on)
    2. Sign-on using non-verifiable data (name, password)
    3. Sign-on requiring one or more verifiable attributes
    4. Sign-on with ‘pseudo-identity’, i.e. sign-on with different credentials (no ip, location or cookies to recognize return visits without strict opt-in).
    5. Multiple entitlement issuers (‘verifiers’, such as age for content, city for residency, sports club for membership)
    6. Operation without the need to store user data; personal data remain only with the user.
  3. Reputation and rating
    1. Support for various rating metrics
    2. Rating metrics can have a relationship (derived ratings)
    3. Content, media and users (reputation) can be rated
    4. Reputation metrics can have a relationship (derived reputation)
    5. People can acquire reputation through actions
    6. People can bestow reputation on others
    7. Reputations are personal attributes
    8. Reputation and rating metrics can be ‘normalized’ and used eco-system wide.
    9. Support for up- and down voting within context
  4. Private and public dialog
    1. One-to-one and one-to-n messaging
    2. Messaging history
    3. Support for ‘channels’ on which content can be published
    4. Support for channel subscriptions
    5. Content items can be commented upon
    6. Comments can be commented upon
  5. Discovery, metadata, SEO
    1. Common vocabulary for 
      1. User attributes
      2. Content types
      3. Usage rules / restrictions
      4. Ratings
      5. Dialogs
    2. Standardized schema for content URL’s
    3. Location services providing extra metadata on applications, initiatives and people
    4. End-user configurable discovery agents (trigger on specific metadata or content patterns)
    5. Common search engine optimization services or templates
  6. Content valuation and monetization
    1. Payment facilities (and other value-exchange functionality)
    2. Micro payments
    3. Facilities for dealing with copyrighted material (cc module, see rightsstatements.org)
  7. Versioning and collaborative content
    1. Versioning facility for content, change history
    2. Functionality to support collaboration in content creation and editing

Roadmap

Obviously, the scope and complexity of these functionalities is enormous. In order to be as agile as possible, we will not, at this stage, be making a complete functional or technical design. Having said that, we envision that in 2019, we know we will be looking at four different types of functionalities that can carry the PublicSpaces label. For each type, we need to determine what existing software could be used as the basis. Listed here are some very probable candidates.

  1. Dialog – completely encrypted end-to-end dialog, based on Signal.
  2. Login and sign-on – based on IRMA.
  3. Commenting and discussion – based on ISSO.
  4. Content sharing multimedia-platform – based on Peertube

Finally

We should make it clear that this is not a final proposal. It’s in fact a working document. We would invite you to use the contact form of this website to share your ideas with us. We’ll update you on a regular basis.

Gerelateerd