AP => Bluesky: add link to original post if truncated

[snarfed]

Related to #976

[snarfed]

More ideas in #1002! (Merged in here.)

[Fauli1221]

Would that also apply to media Bluesky doesn't support like Videos and Audio?

[snarfed]

Maybe!

[snarfed]

Done! Example: https://indieweb.social/@snarfed/112441080098401081 => https://bsky.app/profile/snarfed.indieweb.social.ap.brid.gy/post/3kshvvi466tb2 . Presentation could be better, ideally we'd include an image if available, but it's a start.

[mackuba]

Hmm, suggestion: maybe do "(…)" instead of just "…" at the end? It's not immediately clear that the post was truncated and is not just a normal post that just happens to end the sentence with an ellipsis…

Current:

Proposed:

[snarfed]

Good point! Reopening.

[mackuba]

Btw, I'm adding a way to load the full contents from the Mastodon API and paste it inline to Skythread now 🙂

[snarfed]

Oh, awesome! Or you could fetch it via AP. You'd need to sign those fetches and serve a minimal AP actor with the public key; not sure if that's net more or less work than registering Mastodon OAuth clients dynamically per instance.

[snarfed]

That gives me another idea: I should store the full text in a custom field in the Bluesky record!

[mackuba]

That gives me another idea: I should store the full text in a custom field in the Bluesky record!

Omg yes!!

[mackuba]

Oh, awesome! Or you could fetch it via AP. You'd need to sign those fetches and serve a minimal AP actor with the public key; not sure if that's net more or less work than registering Mastodon OAuth clients dynamically per instance.

I haven't worked with the "low-level" AP API at all yet, just with the Mastodon REST one… and it's just one simple fetch here: mackuba/skythread@540a8b2#diff-1989dcd9cd0d832606735cbad270705ed51ae39d039b915672d37c9828e2da25R388 (it won't work for non-Mastodon instances, but I guess that won't be needed if you add that field :)

[snarfed]

Oh right, I forgot that big chunks of the Mastodon API are open, no auth needed. sgtm!

[jonpincus]

(it won't work for non-Mastodon instances, but I guess that won't be needed if you add that field :)

A lot of non-Mastodon instances support the API so that apps work so you might be okay

[AtiusAmy]

I feel like this would be a good solution to content warning as well just have the CW and then load full post maybe

[snarfed]

I feel like this would be a good solution to content warning as well just have the CW and then load full post maybe

The catch is that we have no control over client UIs, whether official ones like https://bsky.app/ and the mobile apps or any others. We can't add a "load full post" button or link.

[qazmlp]

I think it would still be useful to have the full CN text¹ and hidden text/attachments as custom fields on the bridged posts, both distinct from the mechanism for text that was just truncated to avoid mixups. That would allow third party apps to implement this flow without hitting the origin instance (i.e. better for privacy) or worrying about whether it supports the Mastodon API or if there's an implementation difference on the AP level.

Footnotes

1. or a fragment indicating which part of the text is the CN, as that way you don't have to worry as much about whether UIs validate it matches presentation on Bsky, in case other PDSs use your lexicon to spoof something there. ↩

[snarfed]

Anyone know the etiquette for choosing field names for custom fields in app.bsky.* lexicons that you don't own? I'm not sure what to name these fields. eg fullText, bridgyFedFullText, fediverseFullText, bridgyFedFediverseFullText, ...?

[snarfed]

Next step for changing the ellipsis string is to parameterize brevity.shorten to take a new ellipsis='...' kwarg: https://github.com/snarfed/brevity/blob/bb3cb14d2225c5401b010648e3e0e1158d82ba4c/brevity.py#L242-L245

[qazmlp]

Anyone know the etiquette for choosing field names for custom fields in app.bsky.* lexicons that you don't own? I'm not sure what to name these fields. eg fullText, bridgyFedFullText, fediverseFullText, bridgyFedFediverseFullText, ...?

I think the answer to that is basically 'don't', according to https://atproto.com/specs/lexicon#authority-and-control.

Is there a way to specify a secondary NSID similarly to how you can import multiple namespaces in AP?

[snarfed]

Is there a way to specify a secondary NSID similarly to how you can import multiple namespaces in AP?

No, there isn't. Custom fields in existing records is generally what people do right now, there's plenty of precedent for it in the ATProto ecosystem. It's true that the docs you linked say:

This is not the recommended way to extend applications, but it is not specifically disallowed.

...but there's no other realistic extension pattern yet.

I guess one way would be to store our own separate records, and publish logic for finding those records. That's much less discoverable or usable than custom fields in existing records though. I haven't heard of any external developers using "sidecar" records like that yet.

[mackuba]

Anyone know the etiquette for choosing field names for custom fields in app.bsky.* lexicons that you don't own? I'm not sure what to name these fields. eg fullText, bridgyFedFullText, fediverseFullText, bridgyFedFediverseFullText, ...?

Hey! I've done some digging for this today. It looks like we're still at the stage where there aren't really any clear conventions for this, or to put it differently, the stage where the conventions are being formed by what we're doing ;)

I've scanned the last few days worth of posts for unexpected record keys, and it looks like the only one of this kind is from the Skeets app by @seboslaw, which I think uses this for the post editing feature. The key there is named skeetsAppHistory.

There are also several non-standard but very generic-sounding keys (and probably in most cases added by mistake), like: via, type, alt, labels etc. This is probably not a good idea.

Some (inconclusive) threads I've found about this:

• Extensions field in records for third-party usage bluesky-social/atproto#1889
• Preservation of not-yet-specified Lexicon fields bluesky-social/atproto#2126
• thread from @seboslaw here on Discord: https://discord.com/channels/1097580399187738645/1097580399187738648/1209469681547747388
  • and subthread: https://discord.com/channels/1097580399187738645/1209471751625641994
  • and another: https://discord.com/channels/1097580399187738645/1202968500319031308
• thread from @badlogic: https://discord.com/channels/1097580399187738645/1097580399187738648/1175608584881569792
  • Mario has apparently used this to store custom fields in the profile record instead to store some user settings there - looks like the key is social.skychat.settings

As I understand it, something like gy.brid.fed.originalPost would probably be technically more "correct". But it looks ugly ;) Something like bridgyOriginalPost, bridgyOriginalPostContent or bridgyFedFullText looks better imho and I would go in this direction (we can bikeshed a bit about the specific name). In any case, apps will probably eventually use both of these conventions and more, and ultimately what matters is only that a key is well defined & documented so that others can make use of it if it makes sense, and to minimize the probability of collisions between 3rd party and Bluesky and between two 3rd parties by doing anything in that direction… I'd think that anything that starts with "bridgy" is extremely unlikely to accidentally create a collision with anything else.

(tagging also @bnewbold)

[snarfed]

Wow, thanks for the detailed investigation @mackuba!

Moving to #1092

[qazmlp]

Hmm, suggestion: maybe do "(…)" instead of just "…" at the end? It's not immediately clear that the post was truncated and is not just a normal post that just happens to end the sentence with an ellipsis…

I just ran into that issue and would like to request the same 😅
[…] to me is the standard shortening, but maybe (…) is more common in English?

Another suggestion, but rather than "Original post on …" I'd like to see

• "Read more on …"
• "See full text and 2 images on …"
• eventually (where applicable) also e.g. "See 1 video on …" if all text is present but some media was truncated

since that feels more descriptive of what can be expected after navigation.

[snarfed]

Agreed on [...]! I've switched to that for both posts and bios. Examples: https://bsky.app/profile/snarfed.indieweb.social.ap.brid.gy/post/3kumap43apaj2 , https://bsky.app/profile/evan.cosocial.ca.ap.brid.gy

[mackuba]

Hmm, have you changed something there to add the link to original inside the post body instead of as an embed?

[snarfed]

Good eye! Yes, only for posts with images, since Bluesky can't do both images and link embeds in the same post. 😕 Background in #1106 (comment) and bluesky-social/atproto#2575 .

[mackuba]

Ahh, ok, makes sense. I was worried this was a change for all truncated posts :) I saw the discussions about the different embed types, but I didn't realize it was about this. Not ideal, but it will have to do in this case. I think it's better to have this inconsistency with posts w/o images, because otherwise we lose a lot of space for text in those too.

[mackuba]

Alternatively, you could possibly link just the "[...]" to the original post instead of adding a second [] with "original post" below? But that might be not obvious enough I guess.

Like:

This is a very long post that was truncated becase [...].