Conversation
Notices
-
@mmn @pettter @takeshitakenji i think i agree with @gargron here. last time i checked, i remember thinking gs needed work on conversations
-
@mmn @pettter @takeshitakenji @gargron e.g. i think gs doesn't store the reply-to uri if the notice replied to doesn't exist locally (yet)
-
@mmn @pettter @takeshitakenji @gargron imo conversation_id in gnusocial is only a good idea if it speeds up db-stuff locally
-
@pettter ah, you are right. one-to-one relations is a problem when deleting notices. @mmn @gargron
-
@hannes2peer conversation_id is in place to prevent one of the most annoying things we had to deal with back in 2011 when most of the fediverse ran on statusnet: whenever someone deleted a post, the entire conversation tree would crumble and going into context would just show loose messages, or an individual post. It has a good reason to exist and should not be removed unless you want to go back 6 years in development. While it's not an issue for networks focused in ultra-casual, meaningless interaction, it's highly consequential for any node that values extensive and meaningful discussion, and for any implementation of GNUsocial in a work environment where easily following conversations is required.
-
@nerthos yes you are right, i wasn't thinking!
-
@pettter @mmn @gargron good point.