scuttle-post

I've been collecting ideas for scuttle-post (... which maybe should be scuttle-thread if likes are included). It's a family member which collects all the commonly wanted actions around post messages.

Things I want all in one place

• a function publishThread({ text, channel }, cb)
• a function publishReply({ text, root }, cb) which takes care of the detail of branch etc
• a function publishNestedReply({ text, nestRoot }, cb) likewise takes care of the fork, branch root details

• a function publishFork({ text, forkRoot }, cb) .... this creates a hard fork which doesn't share the same root as this original thread, but points back to the place that was forked from

• a function getThread(root, cb) which builds a thread document which sorts, and files nested replies, and loads in any drafts of replies that were underway

I think the composer could be part of this module - a fairly dense piece of logic (managing attachments, mentions, context of who has spoken in thread, preview, recipients for private msgs), that is currently repeated in multiple places . And drafts functionality should also be attached to the composer, and drink up the context that a draft is being composed in (the thread, and where this compose is in the thread).

Is this similar to what you might be doing with ssb-threads @andrestaltz ?

Another feature (for observeable threads) I really want: when a person starts composing, lock the thread observeable so that it doesn't update while the person is writing - this is a distraction and means the context within which you're writing might need to change. Also behind the scenese reflect this by locking the branch to the context within which you're writing. Optionally you could have a clam (or calm!) notification telling you if new context has rolled in.

p.s. this is what I plan to implement for forks / nested replies : %Ff29qCa...

It was discussed a bunch with a good number of people. Patchwork currently does nested replies by using the branch property - which feels like a hack which uses a property I think should only be for causal determination to manually move a message into position by "faking" it's causal position. This works ok but I personally think is a muddling of concerns.

I'll write more comments later, but now I'm in a hurry and just want to leave an important comment:

I think we should start supporting post messages that have the actual text content as a blob. Authors may want to soft delete that blob if they regret posting it. I make the distinction between soft delete and hard delete, where soft is when you agree to not replicate something anymore, while hard would be the absolute and instantaneous "right to be forgotten", which we know is impossible to guarantee in p2p. I think we should start work on allowing soft edits and soft deletes, and I'm considering that the mmmmm clients would have that from the beginning.

It doesn't pertain so much to this thread because gladly we're talking about other metadata fields, but since we're at it, we can reconsider the whole thread system.

good point @andrestaltz

hey @inoas there's a tag system in the works, you're describing it well :) It's underway and nearly ready for some testing, stay tuned.