Cross Posting Origin

Lexicon Community
,
1

I had an exchange today that has me thinking.

Some statements to set us up here:

  • a post might be cast into a variety of additional lexicon to appear in more apps than its origin
  • origin posts might be in the atmosphere, or external
  • a traceable linked tree of typecast posts would be useful

The thread linked mentions the case of a Grain post being crossposted to Bluesky. When Sifa aggregates the activity of that user, it sees two posts where there really should be one.

Another form of this is bridged posts. Bridgyfed includes the original content of a mastodon post inside of the bridged bluesky record.

Bridgy includes both a copy of the original content and a bridgyOriginalUrl.

So what can we do to smooth this process over? Ideally any post that is a new representation of another post should link back to the original. Perhaps a community.lexicon.post.origin, intended to be used as a field within records.

{
  $type: "community.lexicon.post.origin",
  crossPostOrigin: URI // ATURI or URL to original post
}

If the post is a crosspost of another atproto record, cite its ATURI, otherwise if it is an external source (fediverse, instagram, etc) leave a URL.

This would have multiple use cases. In the instance of a Grain post, the subsequent Bluesky post could link back to the source Grain post via a property of type community.lexicon.post.origin.

Take this modified version of at://did:plc:pqerwmnouevyltxyoayhholf/app.bsky.feed.post/3mjacvozery2s

{
  "tags": [
    "grainsocial"
  ],
  "text": "📍 Sam Adams Boston Brewery\nBoston, Massachusetts, US\n\nA vibrant conversation around the fire at Sam Adams Boston Brewery\n\nhttps://grain.social/profile/did:plc:pqerwmnouevyltxyoayhholf/gallery/3mjacvmgzzg2z\n\n#grainsocial",
  "$type": "app.bsky.feed.post",
  "embed": {
    "$type": "app.bsky.embed.images",
    "images": [
      {
        "alt": "A group of people standing around a fire pit in an outdoor area.",
        "image": {
          "ref": {
            "$link": "bafkreihno2dfgk4jw2amlgrc22rowh54aucutkh4km26hdf6qmnkgzxiai"
          },
          "size": 830112,
          "$type": "blob",
          "mimeType": "image/jpeg"
        },
        "aspectRatio": {
          "width": 2000,
          "height": 1500
        }
      }
    ]
  },
  "facets": [
    {
      "index": {
        "byteEnd": 208,
        "byteStart": 125
      },
      "features": [
        {
          "uri": "https://grain.social/profile/did:plc:pqerwmnouevyltxyoayhholf/gallery/3mjacvmgzzg2z",
          "$type": "app.bsky.richtext.facet#link"
        }
      ]
    },
    {
      "index": {
        "byteEnd": 222,
        "byteStart": 210
      },
      "features": [
        {
          "tag": "grainsocial",
          "$type": "app.bsky.richtext.facet#tag"
        }
      ]
    }
  ],
  "original": {
    "$type": "community.lexicon.post.origin",
    "crossPostOrigin": "at://did:plc:pqerwmnouevyltxyoayhholf/social.grain.gallery/3mjacvmgzzg2z"
  },
  "createdAt": "2026-04-11T17:02:34.968Z"
}

As this is a crosspost from Grain to Bluesky of at://did:plc:pqerwmnouevyltxyoayhholf/social.grain.gallery/3mjacvmgzzg2z, I’ve added a field original of the type community.lexicon.post.origin that links to the Grain post ATURI.

That’s the general idea! I could see this being extended or a similar kind of type created to indicate the source client which created a record in a consistent way, but thats out of scope for this post.

I’d love your thoughts and feedback. Would you find this pattern of post referencing useful? Are there any additional fields that you think should be included in such a lexicon? Does my stub at the namespace make sense?

2 Likes
2

Hell yes! This has been on my todo/wishlist for a long time too. I’d much rather use a standardized sidecar record than the current bridgyOriginalUrl field.

We briefly started discussing this a while back in Lexicon for alternate/related accounts · Issue #57 · lexicon-community/lexicon · GitHub . My guess was that it could be based on alsoKnownAs, so that we don’t reinvent the wheel.

I also suspect we’d want a fully separate sidecar record, as opposed to a field in the main record, so that we can use it without depending on every lexicon author to add it. Notably, I’d immediately want to use this with app.bsky, site.standard, etc records, and I’d rather not have to lobby them all to add it and wait until they do.

Definitely open to hearing what other people think too!

4 Likes