๐Ÿป alfajet ๐Ÿ‡ซ๐Ÿ‡ท ๐Ÿ‡ฌ๐Ÿ‡ง is a user on mastodon.xyz. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Upcoming version of Mastodon (2.4.1) will have a delete & redraft function.

@Gargron Interesting. If boosted, does the rewritten show up? Or do boosts disappear?

@HexAllen Also, likes and repiies and other feedback. It's crucial to save those if you're correcting a typo or a mistake. Don't want to remove an old post that's already got feedback on it just to correct a typo.

@drequivalent The abuse problem that Gargron points out is spot on though. It looks liked this is true delete, just reloads your deleted text back into the editor window.

@HexAllen Want to prevent abuse - show diffs between old version and the new, like Gitlab does. What's the actual problem here?

@HexAllen Kinda like this, but more compact. Red is what's deleted, green is what's added. This way you can tell if it's a legitimate edit or a scumbag trying to fool you.

๐Ÿป alfajet ๐Ÿ‡ซ๐Ÿ‡ท ๐Ÿ‡ฌ๐Ÿ‡ง @alfajet

@drequivalent

Diff would be indeed an elegant way of dealing with this but as far as I know there is no concept of revisions (having different versions) in toots. Gitlab can do that because underneath, git is a repository with version control.

Introducing VC would be a radical change in either OStatus or ActivityPub I think. And to be exhaustive, you would also need to implement VC also on media which would have a significant impact in storage requirements.

@HexAllen

ยท Web ยท 0 ยท 0

@alfajet
@Gargron @HexAllen Valid. Although, I don't think the impact will be all that significant really - people don't edit posts all that often.
And, it doesn't have anything to do with radical changes to AP: the standard already supports Updates and Partial updates: w3.org/TR/activitypub/#update-
w3.org/TR/activitypub/#update-
So, in essence, you just send an updated object, an on receiving end you just figure out a diff and show it as needed. You can even just do it dynamically.
You don't even need a full-blown VC, you can just show a diff between the original post and the most recent version of the message, I'm going to go on the limb here and say that it will be sufficient for most cases.

@drequivalent @alfajet @Gargron With 24 years in IT, a patch view would be fine for me, but I would want to teach my mom how to read it.

Anyway, I'm not submitting patches to this project, so I don't expect a vote. I just asked a question, and was happy with the answer I got.

@drequivalent
Good point. But unless the receiver has kept the previous version in cache, they won't be able to perform a diff when they receive the update.
The two options are
1. to rely on the client to manage this (compare to previous content).
2. to implement some form of VC in ActivityPub. As you say it can be minimal: just keep current and last.

1. would be less disruptive but less reliable I think whereas 2 would have knock on effect on all platforms relying on AP.
@Gargron @HexAllen

@alfajet @Gargron @HexAllen How can the receiver "not keep" a previous version of object they are getting updates for? If there's no previous version then there's nothing to update, and the faux "update" can be discarded altogether.

@alfajet @Gargron @HexAllen And yeah, the comparison would kinda rely on the client if that's what you're asking. But so does a lot of things here, an awful lot I'd say.

@alfajet @Gargron @HexAllen
> 2 would have knock on effect on all platforms relying on AP.

Well, it may, because editing is an essential feature. But it probably won't because it all can be done client-side.

I apologize for responding piece-mail.

@drequivalent
I might be wrong but I don't believe the client application keep indefinitely all status in cache. I'd imagine that if the user request access to an old status , the client will refetch a fresh copy from the server. So if an update applies to an uncached status, I guess the receiver will get an update with the new content but as the previous version is no longer cached, it won't be able to preform a comparison.

@Gargron @HexAllen

@alfajet @Gargron @HexAllen Well, the server has to keep both original and an update. Client takes them both if needed and compares.

@alfajet @Gargron @HexAllen Not so much a change in ActivityPub as changing in handling of Activitypub, I think.

@cwebber, could you please provide your take on this, as one of the authors of the standard?

@cwebber
Thanks for the links, interesting comments, although theses ideas seem to be parked for now.

@drequivalent @Gargron @HexAllen

@cwebber
Thanks for the suggestion! I am not (yet?) a member and can't join tomrrow's call as I'll be working at that time I am afraid.

@drequivalent @Gargron @HexAllen

@alfajet @drequivalent @gargron @HexAllen If you aren't yet a member of the SocialCG, you can join through the join button on the right of w3.org/community/socialcg/

@alfajet @drequivalent @Gargron @HexAllen Well, there is a GitPub so some VC will probably get into AP. A diff would be a very useful feature.

@shellkr @alfajet @Gargron @HexAllen Wow. Didn't think of it this way. That in the face of Microsoft-Github deal.

@shellkr
Are you referring to github.com/git-federation/gitp ?
Looks like it's early stage but definitely a good initiative. However I find paradoxal that they decided to host their work on github, though.

@drequivalent @Gargron @HexAllen