Likes/Reblogging

[NfNitLoop]

I wrote in the v0.1.0 README.md:

Reblogging [is an unplanned feature]. I [believe] there should be a higher barrier to sharing others' content. You'll need to comment, post, or "Reply" post to share content to your followers.

But, the more I think about it having a lot of posts like

⬆️ OMG This

is probably even more annoying. If I implement a reblog functionality, I could limit it to the feed, and add an option to not display reblogs for people that don't want to see that.

[NfNitLoop]

I think I've convinced myself that this is preferable to lots of low-signal-to-noise "reply" posts. I'd rather there be a simple type to represent this, so that users can filter it out if they don't want to see it.

I think I'm going to make a single "like" type that serves as both "like" and "retweet".

• Likes are Items just like anything else.
• They'll appear in your feed. (Though you can (eventually) filter them out if you don't want to see them.)
• From there people can click to see the original post if they want. (Maybe expands in place?)
• You can "like" a thing as many times as you want. Each one gets its own timestamp and appears in your feed. (This lets you go back and re-like some old content again.)
• Caveat: There's no "unlike", since there's no way to delete Items.

[NfNitLoop]

Request from a friend: support emojis for likes/reactions. Helps with quick responses. Is great for accessibility.

maybe make a generic “reaction” type that accepts any emoji.

[NfNitLoop]

Brainstorming on this implementation a bit more:

When there are multiple servers / syncing involved, this could happen:

• Server A: Cody Likes a post by Jill.
• Server B: Bob (who follows Cody) syncs and reads his feed.
• Bob sees: Cody liked [long item signature] by [long, unknown user ID].

Because no one on server B follows Jill, not only can they not easily load Jill's post and profile (to determine Jill's display name), but they can't even rectify the issue by syncing those Items onto the server because Jill is not allowed to post content there directly.

To solve this, we'll want to allow "embedding" those Items within the like/reblog. Essentially they'll become a new kind of file attachment. Unlike the existing sha256-based file attachment signatures, these can use the existing UID & Signature combo to validate attached Items.

The key here is that we don't actually have to embed the full content inside of the protobuf (which is where my thinking had gone previously). By letting them be referenced by ID, and stored on the server like files, they get automatic de-duplication in the content-addressable store. If we additionally update storing of Items themselves to go directly into the content-addressable store (#93) they can even be deduped with those.