Brainstorming

This page captures our consortium's ideas as to what direction to take our work in for follow-on funding. We settled on applying to NLnet Assure for the call closing 1st October 2022.

Vision

Our vision is to transform how multiple parties collaborate on task-tracking across organisational boundaries, as an exemplar of how multi-organisational collaboration can be achieved more generally.

We decided to augment the Federated Timesheets network to support issue-tracking as well as timesheet entries, under the category of tasks. The rationale was that a timesheet entry can be linked to a task, and issues generate tasks to resolve them (see below for an example Problem Statement). The network is intended to integrate external third-party issue-tracking tools (e.g. GitHub Issues), as well as federate participating tools such as Tiki. Since issues involve data that need to be shared more urgently than those in timesheets, the proposal includes incorporating live data into the network using m-ld, such that some issue-trackers share high-urgency data between clients and instances. The network is intended to show data being propagated in a federation in both a conventional way (via REST request/response) and live (with multi-party edit possible).

Milestones Proposed

Milestone 1 - theoretical groundwork

Revise federation protocol to take account of:

• Learnings from Federated Timesheets project (including signatures)
• Access control over ripple propagation (forwarding trust model)
• Sharing of routing information
• Monitoring (e.g. "long spinners")
• Needs of live-sharing concurrency models, e.g. CRDTs
• "Locking" to allow nodes to claim to be the source of truth (temporarily)
• What is practical to implement in Milestone 2 & 3

Milestone 2 - collaborative Tiki

This involves enhancing Tiki to incorporate live data sharing, initially of issue-tracking core information:

• Between client devices connecting to one Tiki deployment; and
• Between separate deployments of Tiki (system-to-system collaboration)

This is intended to run in parallel with Milestone 3.

Milestone 3 - federation of issue-trackers

This is to federate multiple issue-tracking systems, including Tiki, using the revised protocol established in Milestone 1, with Prejournal acting as the integration engine for connectors between federated systems, and integrations with external systems such as SolidOS’ issue-tracker, GitHub Issues, etc.

This is intended to run in parallel with Milestone 2.

Milestone 4 - incorporation of live data into federation

The plan is to incorporate m-ld-enhanced instance Tiki into the federation for support of both live and replicated data. The resulting federation of systems is intended to be used for real-world issue-tracking for both this project and other related ones.

Milestone 5 - documentation & project management

One of the governance learnings from the Timesheets project was that it would have benefited from some oversight and a clearer scope for project documentation, so this was added explicitly to the project's scope.

Motivation for extending scope to issue-tracking

Issue-tracking is regularly a multi-organisational and multi-system endeavour, with contributions drawn from the ranks of both individual freelancers / volunteers, and corporates / SMBs. The time-criticality of some bug categories (such as security vulnerabilities) makes it advantageous for all participants to have access to the same data, but in the different issue-tracking tools each party uses. If, for example, a SaaS provider uses open source components for their application, and an issue is reported to them by a customer, that issue will need to be tracked to resolution. The underlying cause of that issue might be a bug in a supporting open source component, which would be raised as an Issue on its public repo (e.g. GitHub). Furthermore, the end customer may have logged the original issue in a system internal to them (e.g. Atlassian's JIRA), and wish to track it there too, but with additional internal-only data. Being able to federate these bug-tracking systems to share relevant data about issues would improve productivity and data integrity.

Problem Statements

Live Collaboration

It can be complex to fill out details of a bug tracking form during the ticket's lifecycle. In a work planning meeting, for example, it can be wasteful and frustrating to wait for the one person who has the ticket locked to type in information, especially if other people are better qualified to fill in some parts of the form.

It would be better to have everyone in the meeting able enter relevant data in the form, and correct others as they type, as in a shared document. This solution should also apply to other collaborative parts of the workflow, such as Wiki pages.

(Note that multi-player editing does not mean chaos, because people naturally co-operate; it is preferable for the human collaboration to be the limiting factor instead of the software's locking behaviour.)

Access Control

To investigate whether and how we might use m-ld in a federation bug tracker, considering the following simple product description.

Say companies A, B and C collaborate on a bug. It has a status (open/closed) and a list of comments. Each comment has a text string (the comment), an author-employer enum (A, B or C), and a status (draft/final).

Bug:
  Status: open / closed
  Comments: Comment[]

Comment:
  AuthorEmployer: A / B / C
  Text: string
  Status: Final / Draft

So there are basically 7 access areas:

• 1: bug status
• 2a/b/c: draft comments from company A / B / C
• 3a/b/c: final comments from company A / B / C

In the node of company A, company A itself has "owner" role, and can do anything.

Company A gives company B a "partner" role, meaning they get read access to all 7 areas and write access to areas 1, 2b and 3b.

Company A gives company C an "observer" role, meaning they get read access to areas 1, 2c, and 3a/b/c, and write access to areas 2c and 3c.

Solving this in a monolith MVC application

• The controller would have methods Status.get, Status.set and Comments.list/get/add/update.
• There would be some method annotation or if-statement at the beginning of the controller function, indicating that setStatus is restricted to owner+partner.
• The Comments model would have a method canRead (returning true for partner+owner and if status is final) and a method canWrite (returning true if the user is from the correct AuthorCompany).
• The Comments.list function would filter based on canRead.
• The Comments.get function would throw an error if canRead returns false.
• The Comments.add/update functions would throw an error if canWrite returns false.

Pretty straightforward, but the trouble is we want companies A, B, and C to each have their own sovereign server, and we want real-time diff propagation between them.

Solving this with m-ld

See this Gitter discussion for details.

Solving this with Ponder Source Prejournal

There are 3 possible answers to what Prejournal is: a script, a hosted app, something in-between. See Prejournal Issue 173 for more background. Assuming it will become that "something in-between", the solution to this Access Control problem would be what Michiel de Jong has sought to capture in Prejournal Issue 174.