Federation error with "undrafted" articles #221

Closed
opened 2018-09-14 11:04:52 +00:00 by bannisdale · 6 comments
bannisdale commented 2018-09-14 11:04:52 +00:00 (Migrated from github.com)

I was wondering why a certain post didn't show up in my Mastodon timeline.

I ran a few tests and realized: It's because it was a draft before. So from my tests, there are two scenarios:

  1. Post an article. It gets federated (shows up in my Mastodon feed)
  2. Save an article as draft. Then edit it and publish it ("undraft" it). It won't show up.

I assume it's because the post is initially federated (without visibility) and technically edited later on, but Mastodon doesn't support editing.

Workaround so far is writing the draft until it's final, then copy the text, create a new post with it and then delete the old draft. Obviously, that's a bit lackluster. :)

I was wondering why a certain post didn't show up in my Mastodon timeline. I ran a few tests and realized: It's because it was a draft before. So from my tests, there are two scenarios: 1. Post an article. It gets federated (shows up in my Mastodon feed) 2. Save an article as draft. Then edit it and publish it ("undraft" it). It won't show up. I assume it's because the post is initially federated (without visibility) and technically edited later on, but Mastodon doesn't support editing. Workaround so far is writing the draft until it's final, then copy the text, create a new post with it and then delete the old draft. Obviously, that's a bit lackluster. :)
kvibber commented 2018-09-21 05:50:40 +00:00 (Migrated from github.com)

Additionally, I found that changing the title between the first draft and the published draft updates the URL of the blog post, but doesn't update the link in the federated post that gets into Mastodon if you search for the URL to manually pull it in. So you can make the post title and link visible, but the link is broken, because it's pointing at the old URL.

I followed @bannisdale's workaround and deleted/re-created the post to get around it.

Additionally, I found that changing the title between the first draft and the published draft updates the URL of the blog post, but doesn't update the link in the federated post that gets into Mastodon if you search for the URL to manually pull it in. So you can make the post title and link visible, but the link is broken, because it's pointing at the old URL. I followed @bannisdale's workaround and deleted/re-created the post to get around it.
elegaanz commented 2018-09-21 17:20:29 +00:00 (Migrated from github.com)

@kvibber there is another issue for your problem there: #207 🙂

@kvibber there is another issue for your problem there: #207 :slightly_smiling_face:
kvibber commented 2018-09-21 20:44:46 +00:00 (Migrated from github.com)

@BaptisteGelez Thanks, I didn't see that one!

Looking at the interaction between the two bugs, it seems it would make sense to update the URL when changing a draft's title, but not when changing a published post's title.

@BaptisteGelez Thanks, I didn't see that one! Looking at the interaction between the two bugs, it seems it would make sense to update the URL when changing a draft's title, but not when changing a published post's title.
trwnh commented 2018-10-11 22:33:02 +00:00 (Migrated from github.com)

Ideally Mastodon would support Update activities, but there is another solution: federation permalink can be ID-based instead of title-based, and a "pretty url" can be formed from a custom slug containing the title or whatever the user enters.

So, for example, I might post an article on Plume that federates out as https://plume.example/~/trwnh/6743826481264 and the title is test post. The default pretty-url slug would be test-post (but I could edit it manually to test if I wanted to, or 2018/10/11/1, or 2018/testpost, or whatever I wanted) and then the URL would become https://plume.example/~/trwnh/test-post (or whatever i set it to)

When federating that out, you would use the id as that permalink, and url as the slugified link. So for example:

"id": "https://plume.example/~/trwnh/6743826481264",
"url": "https://plume.example/~/trwnh/test-post",

And the content of the Create activity would include the id instead of the url. So something like <p>$title - $id</p> at the simplest, and then it would show up in Mastodon like this:

trwnh (@trwnh@plume.example) posted 23s ago:
-----------------------------------------------------------------
test post - https://plume.example/~/trwnh/6743826481264
-----------------------------------------------------------------
[reply] [boost] [favorite] [menu]

or trwnh posted a new article:<br>$title<br>$id, and then it would show up in Mastodon like this:

trwnh (@trwnh@plume.example) posted 23s ago:
-------------------------------------------------------
trwnh posted a new article:
test post
https://plume.example/~/trwnh/6743826481264
-------------------------------------------------------
[reply] [boost] [favorite] [menu]

The important thing is that the URL that gets federated out cannot change, so it's a bad idea to use a value that can be changed. Not every implementation might support Update activities, so using the id is more robust and will fail in less cases.

Ideally Mastodon would support Update activities, but there is another solution: federation permalink can be ID-based instead of title-based, and a "pretty url" can be formed from a custom slug containing the title or whatever the user enters. So, for example, I might post an article on Plume that federates out as `https://plume.example/~/trwnh/6743826481264` and the title is `test post`. The default pretty-url slug would be `test-post` (but I could edit it manually to `test` if I wanted to, or `2018/10/11/1`, or `2018/testpost`, or whatever I wanted) and then the URL would become `https://plume.example/~/trwnh/test-post` (or whatever i set it to) When federating that out, you would use the `id` as that permalink, and `url` as the slugified link. So for example: ``` "id": "https://plume.example/~/trwnh/6743826481264", "url": "https://plume.example/~/trwnh/test-post", ``` And the `content` of the `Create` activity would include the `id` instead of the `url`. So something like `<p>$title - $id</p>` at the simplest, and then it would show up in Mastodon like this: ``` trwnh (@trwnh@plume.example) posted 23s ago: ----------------------------------------------------------------- test post - https://plume.example/~/trwnh/6743826481264 ----------------------------------------------------------------- [reply] [boost] [favorite] [menu] ``` or `trwnh posted a new article:<br>$title<br>$id`, and then it would show up in Mastodon like this: ``` trwnh (@trwnh@plume.example) posted 23s ago: ------------------------------------------------------- trwnh posted a new article: test post https://plume.example/~/trwnh/6743826481264 ------------------------------------------------------- [reply] [boost] [favorite] [menu] ``` The important thing is that the URL that gets federated out cannot change, so it's a bad idea to use a value that can be changed. Not every implementation might support `Update` activities, so using the `id` is more robust and will fail in less cases.

This is now fixed, #207 is too, however @trwnh's suggestion might be a better way of handling post title update. Shall we open a new issue discussing if this should be done?

This is now fixed, #207 is too, however @trwnh's suggestion might be a better way of handling post title update. Shall we open a new issue discussing if this should be done?
trwnh commented 2018-10-29 05:57:30 +00:00 (Migrated from github.com)

@fdb-hiroshima I can do that, if you wish.

@fdb-hiroshima I can do that, if you wish.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Plume/Plume#221
No description provided.