Allow reblog to be 'undone'

This limit has always been there, but I don't fully understand (more so now that we use hivemind for everything) why a reblog cannot be undone.

If I reblog a post and the author is allowed to change the post content I should be allowed to 'remove' the reblog.

added feature label

I fully support this and would like to know the reasons why we cannot do it, if anyone knows about them.

I'm not aware of any, but we're not to the point of adding new features to hivemind quite yet (probably we'll be there soon, just a few more things to finish and test).

Looking at the old code it looks like it was a working feature (reblog-delete), but now it seems broken. At first glance it will only do its job when that operation is in the same pack of blocks processed as a group, that is, it prevents flushing of new reblogs that were canceled soon after - even then it won't work correctly in all cases.

Edit: my bad, I've missed one call since I expected deletion process to be accumulated and flushed like new reblogs, but it is done right away. So it should work in general, except one case that will be detected by one of the scenarios below.

I propose the following tests:

1. reblog followed at some distance by reblog-delete, but in the same pack of blocks during initial sync
2. like above but both in the same block, preferably during live sync
3. like 1. followed by renewed reblog of the same post, still in the same pack of blocks
4. like 2. followed by renewed reblog of the same post, still in the same live block
5. reblog then reblog-delete during initial sync but in separate packs of blocks
6. reblog during initial sync, reblog-delete during live sync
7. both reblog and reblog-delete in separate live blocks

and for the good measure

8. reblog/reblog-delete authorized by someone other than blogger (two versions: unrelated account or post author that is not the same account as blogger)
9. reblog-delete of post that never existed
10. reblog-delete of post that was deleted (in the same pack of initial sync blocks, in different packs, operation in live block while delete in initial sync, both in live blocks - same or different)

assigned to @dkedzierski

added Doing label

mentioned in merge request !441 (merged)

mentioned in issue tasks_without_projects_yet#29 (closed)

closed

@bwrona closed because it's done? I mean it's available? Can you share a sample json operation?

@asgarth If you look at status above on this page, looks like the functionality was merged in MR 441.

Thanks, I've seen it. Not sure if it's already deployed and if I can test it.

If it's available I'll check the code and figure out how to make it work ;)

@asgarth From what I understood, you simply issue a reblog custom_json operation with the following data:
["delete",{"account":"account_name","author":"author_name","permlink":"post_permlink"}]

@dan @arcange sorry for taking so long before sharing feedback on this one. I tried to delete a reblog but it's not working as expected. Maybe I'm doing something wrong?

In this transaction I reblogged a post: https://hiveblocks.com/tx/33f5d8f864cbbd0bb9b4e3e4cf20616431e5f720

Later I tried to remove it: https://hiveblocks.com/tx/4ab4c29760232618b2893f328af11cf65015ee5a

But as you can see the post is still there: https://hive.blog/@asgarth-dev

@asgarth you issued a "follow" custom_json. You need to issue a "reblog"

I issued a 'follow' also for the reblog:

...but I'll give it a try ;)

Done: https://hiveblocks.com/tx/02b9f9df65dd4cc165bc29a9dad1b9d880c502b8

Post still there

The first transaction (id = follow with reblog in json) actually activating reblog is a bug in Hivemind caused by reuse of the same function to handle both follow and reblog. For both cases the scheme is the following: "id":command_str,"json":[command_str,data_dict] so correct reblog looks like this:

"id": "reblog", "json": ["reblog",{"account":"asgarth-dev","author":"peakd","permlink":"peakd-core-values-and-home-page"}]

and correct reblog-delete looks like this:

"id": "reblog", "json": ["reblog",{"account":"asgarth-dev","author":"peakd","permlink":"peakd-core-values-and-home-page","delete":"delete"}] (yes, the same as above with just "delete":"delete" added to data)

Note, that different scheme used to work (which made more sense IMHO) but only up to block 6mln for some reason: "id":command_str,"json":data_dict

It worked ...thanks!!!

So better to switch to reblog for the id right? Both for reblog and delete?

Ok, small update. I've looked at the old code (from HF23) and it looks like the problem is different from what I saw in new code. The first transaction was actually ok for old code because reblog apparently was part of follow command. Reblog-delete also worked (the same way as today - just repeat the same operation as in reblog with "delete":"delete" added to data). Why "reblog" was later introduced as new type of "id" is something I don't know. The examples I've given above should work ok, but it looks like if you change value of "id" to "follow" in them it should also work and it is not a bug because it used to work like that by design.

I'm not completely sure, but if I remember this right before HF23 both follow/ignore and reblog were all stored in the same DB table. This is why both used follow as id.

@ABW and thanks for the quick reply :)

IMHO, having "reblog ...reblog ...delete:delete" is all but intuitive. Poor design of an API call, unless someone can explain to me why it was designed like this.