Comments do not federate thread_parent_guid attribute as stated in doc

[tclaus]

In documentation the thread_parent_guid attribute is part of the comment entity.
Is this attribute really distributed? If not, this would be nice to see this in next release of federation protocol.

[SuperTux88]

It isn't in the library yet because diaspora doesn't support threads in comments yet. It is in the protocol specification because Friendica is already using it. When it gets added to the library, it needs to be actively added to the diaspora database and handled everywhere, that's the reason why it wasn't added here yet. Now it implicitly just works with the additional_data (so federation between friendica and diaspora correctly handles the field and forwards it with a valid signature), but when it gets explicitly added to the library that stops working and it needs explicit handling and support from the diaspora side.

Since it's only a field, it can be added relatively quickly if needed.

[tclaus]

In one of my dreams, I have seen this attribute in a database.. Butt this just was a dream..
By the way: A comment in Diaspora already is a "Commentable" so it is prepared to comment a comment in terms of infrastructure.
If a comment ever can comment another comment, Diaspora has to decide to view these comments on older clients (commentable_type is the still the root post) and introduce the thread_parent_guid.
Or when receiving a comment, weather from friendica or another diaspora the commentable_type is mapped on the real parent comment ( type: "Comment") . Older clients then will not show these in its UI. But that's just another reason for admins to update.

Of course, diaspora then needs a minimal change to show sub-comments, and a bigger change in UI and handling.
whatever - then no change in protocol-code is needed, but a decision has to be make.

[SuperTux88]

I have seen this attribute in a database.. Butt this just was a dream..

It is in the database, as data, on comments that are in a thread (comments received from friendica) in the additional_data.

By the way: A comment in Diaspora already is a "Commentable" so it is prepared to comment a comment in terms of infrastructure.

A comment isn't a "Commentable", neither in diaspora, nor in the protocol specification. The only allowed comment parents are posts (status messages or reshares). If you comment on a comment you need to have the parent post still as parent, because only then the federation of the comment works, because only the post knows to where it was federated, and the comment to which you are responding goes into thread_parent_guid.

Older clients then will not show these in its UI.

Old diaspora versions will just display the comments in chronological order without the thread information, like diaspora currently just shows friendica comments without the thread information, but still correctly federates the thread information to other servers (for example back to another friendica which then displays the thread information again).

Of course, diaspora then needs a minimal change to show sub-comments, and a bigger change in UI and handling.

As said, the changes here in the library are easy and can be done quickly (only add the attribute at a few places), but the changes in diaspora to actually support the attribute are probably more work. So it's probably better to prepare the diaspora side first before adding the attribute here.

[tclaus]

Now I know about "comments_signature" table and the additional_data there. Thanks for clarification.

[tclaus]

If diaspora would support threaded comments - could these parent_guids simply written back to the additional_data and getting federation for free?