Linking between projects and activities

[holkexyz]

In #33 we introduce the project schema.

In contrast to a collection, where a hypercert can be part of many collections, a hypercert can only be part of a single project.

A solution for that adding a project field in the activity schema instead of linking to the activities from the project. However, then anyone can add their hypercert to other users' projects. Hence, we need a bidirecitonal link. Is that thinking correct?

Is this the best implementation?

• Keep the link from the project schema to the activities (an array)
• Add a project field in the activity schema (single value)

Or are there alternative ways to do this?

[aspiers]

It sounds like you're essentially describing a similar scheme to your new badge awards/responses for acceptance model, so that the owner of the activity gets to pick a single project for it to belong to, but this isn't validated until the project "accepts" the activity by including it in the project's activities[] array.

I think this is fine, however we do have to acknowledge that there is no way to enforce referential consistency here; we can only validate after the fact using AppViews etc. (Could also use WAVS or other verifiable compute.)

This is exactly what I was referring to in https://www.notion.so/Safe-metadata-mutability-272d7a3bc90d80d99b2ad2262a7d448e?source=copy_link#28fd7a3bc90d80328614ff42e1172979

[aspiers]

BTW if we built an AppView endpoint which makes it easy to verify / discover "validated" project activities, then we could add in a special exception for activities which are in the same repo as the project record - in that case they originated from the same user or organization, so they shouldn't require acceptance, only a link from the activity to the project.

[holkexyz]

Yes, correct. When I created the badge.response I also thought that we could create a more general schema that applies to other flows as well (I didn't think of this one though). I decided for a dedicated response to the badge as simpler for interpretation though.

And yes, we can't enforce referential consistency. If we want to do something like that, we could use a flow like the blue badge, i.e. I first get the approval from the activity claim creator and then include it with that proof in my project.

At this point, I think it is even sufficient to just have your own activity claims in your own project. When users ask for the feature to include other user's activity claims, we can add this.

I think nothing in our current setup, prevents it from being added later. However, we might want to make a decision if we already want to include a project field in the activity claim.

[aspiers]

However, we might want to make a decision if we already want to include a project field in the activity claim.

We already have it since yesterday, thanks to your PR #33:

e1c2198#diff-583e5bf1dcef162cb1248d735545825268833865e64e9db258f748d85d039ae0R76-R80

[holkexyz]

oh, great, decision done:)

[aspiers]

We discussed this again yesterday and decided we want a separate org.hypercerts.acknowledgement record (or similar) for not just this scenario of activities accepting inclusion into projects, but also contributors accepting inclusion of their contributions into activities, and other similar scenarios.

It could be modelled something like:

{
  "subject": <strongRef>,     // activity or contribution
  "container": <strongRef>, // project or activity
  "decision": <bool>,
  "comment": <string>
}

UPDATE: filed as #63

[aspiers]

Actually we're still considering using labels instead of this.

[s-adamantine]

We've decided that we will have a collection lexicon, that also extends out to the project lexicon. A collection can be anything.