Distributed issues / tickets possible via AP?

Dear community,

this is Matthias, I’m working on a platform called “Klarschiff” (de: cleanship) that allows civic feedback about potholes, broken signs etc. We are also participating on the Open311 / citySDK protocol to allow 3rd party apps to submit tickets.

As more and more cities in our state adopt the platform, we are brainstorming, if there is the possibility to form a federation? So all servers form a network, that allows organisations to work to gather to solve the submitted issues. Currently we think about the following features

  • move tickets between instances
  • move users / groups between instances
  • get all tickets of all instances
  • (bootstrapping, discovery, security, load, …)

While I hang around the fediverse and learn the very basics of activitypub, I currently don’t see, if this would be possible by design? And if so, what standards do refer to this aspects?

There is forgefed that needs also to cover the ticket thing (for software projects to work on feature requests / bugs), but for me it’s hard to see, how they will address this aspect?

Any thoughts and hints on wip would be appreciated!

P.S: Somewhat this is a crossposting from the old forum https://socialhub.network/t/generic-issue-pattern-civic-participation-city-planing/588

4 Likes

I would very much also like to see a flexible spec for tickets on top of ActivityPub. I’ve been involved in the ForgeFed specification work and I don’t see why a non-forge platform couldn’t use the proposed Ticket type for example to handle distributed tickets in a system like the one you work on.

The key is that we get enough people on board to ensure ForgeFed is suitable for this purpose. Otherwise there is risk of two incompatible specifications / extensions on ActivityPub for tickets, which would be sad for interop. Tickets are not just software development, they can be things like on your platform or project management of any sort.

If you (or anyone else) are interested, there is a rather important design decision to be made regarding the creation of tickets re ForgeFed - would be great to get some insights on that.

I very much like the idea of distributed issue tracking for more than just collaboration on code.

move tickets between instances
move users / groups between instances

This feature is sometimes called “nomadic identity”. Unfortunately it is not provided by the ActivityPub protocol. It is very much requested (see discussions at APConf).

Other than that I think it would be feasible to implement a issue tracking system on-top of ActivityPub. I believe the only thing needed is a vocabulary that specifie the issue tracking procedure.

There has been some work to define such a vocabulary (Linked Open Vocabularies is a great resource for discovering such vocabularies):

If we have such a vocabulary it could be used as such:

Create a new issue

Instead of creating a “Note” or any object type defined by ActivityStreams Alice creates an Issue as defined in the fictive “Fediverse Issue Vocabulary”.

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      { "fiv": "https://example.com/fediverse-issue-vocabulary" }
    ],
  "type": "Create",
  "id": "https://social.example/activities/1",
  "to": ["https://chatty.example/ben",  "https://www.w3.org/ns/activitystreams#Public"],
  "actor": "https://social.example/actors/alice",
  "object": {
      "type": "fiv:Issue",
      "id": "https://social.example/issues/1",
      "fiv:title": "Bird house needs to be refilled",
      "fiv:description": "It's winter and the birds are eating a lot of grains from the bird house. Please rifll",
    }
}

Note that the issue is addressed to the public and to Ben explicitly (maybe because Ben is somehow responsible for the bird house).

Note

Comment on the issue (discussion)

Charlie asks a question about the issue:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      { "fiv": "https://example.com/fediverse-issue-vocabulary"      }
    ],
  "type": "Create",
  "id": "https://another-instance.com/activities/2",
  "to": ["https://www.w3.org/ns/activitystreams#Public"],
  "actor": "https://another-instance.com/actors/charlie",
  "object": {
      "type": "Note",
      "id": "https://another-instance.com/objects/1",
      "context": "https://social.example/issues/1",
      "content": "What seeds do the birds like?",
    }
}

This is just a ActivityStreams Note. The context was set to the id of the issue created by Alice.

Alice can reply with another Note:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      { "fiv": "https://example.com/fediverse-issue-vocabulary"      }
    ],
  "type": "Create",
  "id": "https://social.example/activities/3",
  "to": ["https://another-instance.com/actors/charlie",  "https://www.w3.org/ns/activitystreams#Public"],
  "actor": "https://social.example/actors/alice",
  "object": {
      "type": "Note",
      "id": "https://social.example/objects/4",
      "inReplyTo": "https://another-instance.com/objects/1",
      "context": "https://social.example/issues/1",
      "content": "Sunflower seeds"
    }
}

Resolve issue

Ben can change the status of the issue by creating a “StatusChange” object:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      { "fiv": "https://example.com/fediverse-issue-vocabulary" }
    ],
  "type": "Create",
  "id": "https://chatty.example/activities/13",
  "to": ["https://social.example/actors/alice",  "https://www.w3.org/ns/activitystreams#Public"],
  "actor": "https://chatty.example/actors/ben",
  "object": {
      "type": "fiv:StatusChange",
      "fiv:status": "fiv:Resolved",
      "context": "https://social.example/issues/1",
      "fiv:description": "Refilled bird house with sunflower seeds.",
    }
}

Note that three actors from different servers interacted on this issue. Also individual comments and the issue itself are hosted on different servers.

It would probably make sense that one server collects the issue and related object, caches them and offers the servers view of the affairs (including moderation on who is allowed to comment on the issue or who is allowed to resolve the issue.

I believe the main effort we need to collaborate on is to agree on a vocabulary for talking about issues and I would be very happy to continue discussion and work on this.

3 Likes

Wouldn’t it be better to try to define this as an overlapping type and keep compatibility with core types of ActivityStreams. The spec says (par 4.1):

When an implementation uses an extension type that overlaps with a core vocabulary type, the implementation MUST also specify the core vocabulary type.

So then the Create a new issue would have a: "type": ["Note", "fiv:Issue"]

How to map fiv:title and fiv:description to the content property is another matter, but doing like this would allow compatibility with the existing fediverse (if implementations there facilitate parsing the type property as an array).

And then the AP data for a more complex case would be more like in Examples using multiple Vocabularies.