Syndication with mastodon: content is truncated

[jpcaruana]

With X (previously twitter), content had to be truncated to conform with their (ever changing) tweet char limit. On mastodon (depending on the instance I think), we can post more text. It seems to me that Bridgy truncates mastodon syndication in the same fashion as it did with X, see https://indieweb.social/@jpcaruana/110831617954383431 for instance, but I might be wrong here.

Is there a limitation somewhere or could bridgy post more content when syndicating to a mastodon instance?

(Originally published at: https://jp.caruana.fr/notes/2023/08/04/syndication-with-mastodon/)

[snarfed]

Hi! Yes, Mastodon has a 500 character limit, https://docs.joinmastodon.org/user/posting/#text , so Bridgy truncates to that.

[jpcaruana]

The default character limit is 500 characters.

Hi, thank you for your answer. The char limit is a default one, some instances seem to have a higher limit. I assume this would be difficult to accomodate with, instance by instance.
As an example, https://indieweb.social/@[email protected]/110831709271663521 is 675 char long.

(Originally published at: https://jp.caruana.fr/notes/2023/08/04/the-default-character-limit-is/)

[snarfed]

Yes! Looks like that instance is technically hometown, not Mastodon, https://mefi.social/about , but you're still right for Mastodon too. Looks like we could look up each instance's limit with /api/v2/instance and use that: https://docs.joinmastodon.org/methods/instance/#v2 . PRs are welcome!

[jpcaruana]

I would gradly help! I took a look at granary, it seems like the truncate_text_length attribute is set in the constructor: would it be wise to call an API endpoint on the constructor of an object? It looks like an antipattern to me, preventing people from doing isolated unit test and / or using this object in different contexes.
What would you suggest for implemeting this?

(Originally published at: https://jp.caruana.fr/notes/2023/08/04/i-would-gradly-help-i-took-a/)

[snarfed]

Awesome! And funny, we actually already do this:

bridgy/models.py

Lines 252 to 254 in db16a9d

	# https://docs-develop.pleroma.social/backend/API/differences_in_mastoapi_responses/#instance
	'truncate_text_length':
	json_loads(inst).get('max_toot_chars') if inst else None,

...but evidently Mastodon's v1 instance info API object has changed since then: https://docs.joinmastodon.org/methods/instance/#v1 . So maybe all we need to do is update it to look for the new field as well as the old one?

Also, unit test here:

bridgy/tests/test_mastodon.py

Lines 57 to 61 in db16a9d

	def test_gr_class_with_max_toot_chars(self):
	app = self.auth_entity.app.get()
	app.instance_info = '{"max_toot_chars": 999}'
	app.put()
	self.assert_equals(999, self.m.gr_source.TRUNCATE_TEXT_LENGTH)

[jpcaruana]

Nice! I was looking in the wrong place. I might be able to cook some PR, but I suspect some instances still rely on the v1 API.

(Originally published at: https://jp.caruana.fr/notes/2023/08/04/nice-i-was-looking-in-the-wrong/)

[snarfed]

Oh, this is a v1 API response object that we've already fetched. All you'd need to do is look at the new field.

[jpcaruana]

Oh I see, on the instance I use, https://indieweb.social/api/v2/instance/ and https://indieweb.social/api/v1/instance/ speak in v2 API...

[snarfed]

Hey @jpcaruana have you had a chance to try this? Did it work?

[jpcaruana]

Not sure. This post https://jp.caruana.fr/notes/2023/08/05/how-to-synchronize-a-tree/ is 501 chars long and https://indieweb.social/@jpcaruana/110836774445084366 does not contain the last sentence.

When was the production deploy for this update? Maybe I just posted this before? It posted it on Aug 5th, 13:29 CEST (4:29 PDT if I didn’t mess up with time zones).

I haven’t posted anything longer than 500 chars since… I’ll give it another try.

[snarfed]

Hmm. This was deployed around 8/4 11:25am PT, well before your post.

[snarfed]

Oh, indieweb.social has the default 500 character limit: https://indieweb.social/api/v2/instance . You'll want to test on a different instance that has it set higher.

[jpcaruana]

oh, I feel stupid now! :) I am glad I could help people with a higher char limit instance.

[jpcaruana]

I understand where I was misleaded: I can see https://indieweb.social/@[email protected]/110869631107921516 in my feed, but it does come from another instance...

[jpcaruana]

I found https://techhub.social/ with a 1000 char limit and I created an account on it for testing purposes. As I added this syndication to my website and to bridgy, I found myself unable to post from bridgy with this error message:

Try publishing that page from @[email protected] (Mastodon) instead.

Any idea how I could give it a try?

ps: in the mean time I reverted back my public pages with indeweb.social profile link

[jpcaruana]

(I could imagine a use case where you have several Mastodon accounts and want to syndicate to one or antother depending on the content you post: could it work?)

[snarfed]

Definitely a real use case! Sorry Bridgy doesn't yet handle multiple accounts per domain. #629 tracks that feature request. (It wouldn't be easy, sadly. 😐)

[snarfed]

Tentatively closing. Feel free to reopen if necessary!

[JoelOtter]

Hello! Sorry to zombie this, but I'm not sure it's working correctly, or if I'm doing something wrong. My Mastodon instance supports 5000 characters, but this post seems to have gotten truncated down to 500 as normal.

Does brid.gy fetch the character limit on each publish or does it just do it once at signup? If so that might have something to do with it; I changed that character limit just a couple months ago and have been using brid.gy rather longer!

[snarfed]

Hmm! Good hunch, we do store and reuse that per-server limit, and i don't think we ever expire and refresh it yet. We should!

[snarfed]

@JoelOtter short term, if you log in with your Mastodon account, that should re-fetch your server info. I'll file a new issue to expire it.

[JoelOtter]

Hmm, it doesn't seem to! At least, the preview still shortens it - does that work differently?

[snarfed]

Argh no, you're right. Following up in #1698.