I think Repo as DID would allow these records to live on protocol but allow for collaboration. A knot as pds is possible, and doesn’t need to fully comply with the standard pds implementation. It can have its own xrpc endpoints, just needs to implement just enough to connect to relays and get/sync records, blobs.

(this got really lengthy really fast 😅 sorry)

imo git refs COULD be fine as just subscribeRepos endpoints but personally if theyre not accessible via normal atproto pds endpoints, they should probably just be an event stream. this would be a breaking change but since it would move from /events to /xrpc/sh.tangled.git.subscribeRefsor something, the/events` endpoint could be kept around for a while if anything depends on it (ik ive used it once but idk if anything else does? maybe spindles or other tangled infra, i havent looked too deep)

i havent messed w spindles much but an embeded pds could be useful since it would allow compatibility with tap but idk that this is needed

wrt private data i think it makes sense to wait to see how atproto private data forms and go from there

as far as shared data and access control, i dont think versioning is a hard requirement personally. it could be worth having some trusted third party store a list of cid history for a given aturi (but no data) and allow the op to store the data in their own repo. it would allow users to delete their data properly while avoiding malicious history edits (idk how clear that is lmk if i need to rephrase that)

i think collaborative data could be solved by did-for-repo (see not very thought out idea below)

• the knot acts as an atproto pds with ownership of a did:plc for each repo (which contains an atproto pds field and aka as at://did:owner/sh.tangled.repo/rkey which is bidirectioal like handles).
• pr/issue/etc flow could look like below (aturis included to help follow. would have actual tid rkeys)

1. a user creates a pr/issue for the repo. the record could look like:

// at://did:user:a/sh.tangled.data/original
{
    "history": {
        // note that `cid1` is the cid of the fields value (type, prev, and data v1) and not of the whole record.
        "cid1": { 
            "$type": "sh.tangled.data",
            "prev": null,
            /* data v1 */ 
        }
    } 
}

2. the knot sees this pr/issue (via firehose) and creates a record in its pds which could look like:

// at://did:knot:a/sh.tangled.knot.data/history
{ 
    "history": [
        { 
            "uri": "at://did:user:a/sh.tangled.data/original", 
            "cid": {"$link": "cid1"} 
        }
    ] 
}

3. the original user now edits their record. this performed by finding what fields changed between versions, stripping any fields that are the same, and updating their original record like so:

// at://did:user:a/sh.tangled.data/original
{
    "history": {
        "cid1": { 
            "$type": "sh.tangled.data",
            "prev": null,
            /* data v1 */ 
        },
        "cid2": {
            "$type": "sh.tangled.data.override",
            "prev": {
                "uri": "at://did:user:a/sh.tangled.data/original",
                "cid": {"$link": "cid1"}
            },
            /* data v2 */
        }
    }
}

4. the knot recives the update event and edits the history array like so:

// at://did:knot:a/sh.tangled.knot.data/history
{ 
    "history": [
        { 
            "uri": "at://did:user:a/sh.tangled.data/original", 
            "cid": {"$link": "cid1"} 
        },
        { 
            "uri": "at://did:user:a/sh.tangled.data/original", 
            "cid": {"$link": "cid2"} 
        }
    ] 
}

5. the repo owner edits the record. this creates a record in their pds, following the same flow as the op editing the record

// at://did:user:b/sh.tangled.data/override
{
    "history": {
        "cid3": {
            "$type": "sh.tangled.data.override",
            "prev": {
                "uri": "at://did:user:a/sh.tangled.data/original",
                "cid": {"$link": "cid2"}
            },
            /* data v3 */
        }
    }
}

6. the knot recives the create event, checks if the user has sufficient permissions, and updates the history array like so:

// at://did:knot:a/sh.tangled.knot.data/history
{ 
    "history": [
        { 
            "uri": "at://did:user:a/sh.tangled.data/original", 
            "cid": {"$link": "cid1"} 
        },
        { 
            "uri": "at://did:user:a/sh.tangled.data/original", 
            "cid": {"$link": "cid2"} 
        },
        { 
            "uri": "at://did:user:b/sh.tangled.data/override", 
            "cid": {"$link": "cid3"} 
        }
    ] 
}

7. etc etc

• The knot should reject overrides that cause a forked history, and appviews should ignore overrides or OPs not in the history array
• If the OP is deleted, the knot should probably delete the history entry
• If overrides are deleted, appviews could fall back to previous versions or just show [deleted]

Repo metadata could be a standard record in the knot which can be edited by users with sufficient permissions (using standard pds endpoints but with interservice auth)

alternate pr/issue/etc flow:

1. User creates a pr in their repo

// at://did:user/sh.tangled.data/original
{
    "$type": "sh.tangled.data",
    /* data v1 */
}

2. The knot replicates this like so:

// at://did:knot/sh.tangled.data/other
{
    "$type": "sh.tangled.data",
    "source": {
        "uri": "at://did:user/sh.tangled.data/original",
        "cid": {"$link": "original-cid"} // to detect if it was edited, not to break links
    },
    /* data v1 */
}

3. User edits the data in their repo. This change is copied in the knots pds. Note that the source field remains unchanged.
4. A repo admin edits the data. This is done via inter service auth (like repo metadata). The source field is not changed
5. The user deletes their record. The knot updates the source field to be null but otherwise keeps the data (not sold on this one 🤷 but is similar to how gh etc do things)

This makes user owned data like prs and issues not really user owned so idk how i feel about that but these are off the cuff thoughts so 🤷

also i dont really have strong feelings on permissions except if tangled use the current model they should probably just be records and atproto oauth permissionsets/scopes are probably a good place to look for inspo