You are reading content from Scuttlebutt
@andrestaltz %GB1PN9TpBvYsx7Yb5j+XpweuUusnZy9EDPA4kpSLe98=.sha256

Using blurhash to remember blocked feeds

screenshot of an online tool to convert any image to a blurred version represented by a hash code, in this example mix.desktop is used

#ssb-dev #ssb

Hey folks, I have an idea to share. This is something that emerged during talks with @nonlinear about design in Manyverse.

Currently, when blocking someone on SSB (js stack), it just stops replicating that feed, but it doesn't delete their content. This will change soon in Manyverse because block will mean deleting all of that person's content from your device.

One problem that arises from this is that when you stumble upon that SSB ID again, if you open their profile, it'll just show their SSB ID and nothing else. If you're not good at memorizing the IDs, you'll have no idea who was this person that you blocked. (Maybe it's time to unblock them? Or maybe you want to keep them blocked but you want to remind yourself who was this person)

A solution to this is to take a "snapshot" of that person's name + avatar at the time you block them. The snapshot is posted on your own feed, and acts as a reminder-to-self of who they are. The next time you open their profile, instead of loading the profile details that person declared about themselves, it'll open the "snapshot" data you recorded at the time of blocking. That should work!

However, two subproblems: (1) the avatar blob may take too much space on your device, (2) the avatar itself could be offensive, you don't want to see it up close.

Blurhash to the rescue! It takes a small image and generates a small amount of base83 text which can then be converted to a blurred image. And where should be actually publish this snapshot? I was thinking it could be best done on the contact msg itself, the one that declares you are blocking the person.

So instead of publishing msg.value.content

{
  "type": "contact",
  "contact": "@AUtgCIpqOsv6k5mnWKA4JeJVkJTd9Oz2gmv6rojQeXU=.ed25519",
  "blocking": true
}

You would publish something like

{
  "type": "contact",
  "contact": "@AUtgCIpqOsv6k5mnWKA4JeJVkJTd9Oz2gmv6rojQeXU=.ed25519",
  "blocking": true,
  "name": "Alice",
  "blurhash": "ePI}]}j^~noe_1~pj@IYRlxt?ZWDxtj?DlD-ofxtRkt5%LxtM|RkfQ",
}

Thoughts?

(Here are some quick examples of blurred avatars I tested. These are by no means a suggestion to block these people)

example

example

example

@Matt Lorentz %6k312kDtq+pYPoZHeI/PHzQZPlYBTHwQccyHZEq/RwE=.sha256

I love this idea! To me it seems like an about message would be a better place to the blurhash. Maybe a private about message encrypted to yourself. In my mind the job of contact messages is to describe the social graph, and about messages are where we store metadata about people. Granted, profile screens on most clients already need to query both the contact and about messages to build a profile page, but it still seems good to separate the concerns here.

Maybe it even belongs inside the image object on the about message, like this:

{
  "type": "about",
  "about": "@hxGxqPrplLjRG2vtjQL87abX4QKqeLgCwQpS730nNwE=.ed25519",
  "name": "bob",
  "image": {
    "link": "&NfP4H4NZCfiPQ6AZ6fEmilbFL8Hz3wTQVeaxbCnNEt4=.sha256",
    "size": 347856,
    "type": "image/png",
    "width": 512,
    "height": 512, 
šŸ‘‰  "blurhash": "ePI}]}j^~noe_1~pj@IYRlxt?ZWDxtj?DlD-ofxtRkt5%LxtM|RkfQ", šŸ‘ˆ.
   } 
}

šŸ¤” this could even be done when publishing arbitrary blobs, and clients could do things like display the blurred image until the full image is downloaded from peers. That's a different discussion though.

@andrestaltz %bsYEP6TvZ9LH0FZFU6eXsPq5sI2RDweJT4c5fMXLEY8=.sha256

To me it seems like an about message would be a better place to the blurhash.

Nowadays I'm quite conscious about storage usage, and with this proposal I'm trying to avoid publishing too many things. Co-locating the profile snapshot with the contact msg helps because all the overhead (signatures, msg metadata) is shared, and you wouldn't have to publish two messages as a "transaction". Semantically, it doesn't seem to me like it's publishing profile details in the way about does, to me it just seems like additional metadata on the contact msg.

this could even be done when publishing arbitrary blobs, and clients could do things like display the blurred image until the full image is downloaded from peers. That's a different discussion though.

Strong yes to this idea.

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@SoapDog (Macbook Air M1) %lK2Z1LYhJDCr2QQdZCPLiEXNEp5bfOE4nfoU1oYfqMM=.sha256

I really like that. I think it should be done as a private msg to yourself.

@Matt Lorentz %HgB1NSrH6Y5/n7QU41i/hAj4/D06uScAAxgbKtWR/Hs=.sha256

@andrestaltz

Nowadays Iā€™m quite conscious about storage usage, and with this proposal Iā€™m trying to avoid publishing too many things.

I'd like to flesh this out a little more. It seems like all your recent work on db compaction and meta feeds would be making you feel less pressure to pack every bit as fully as possible. Why is the opposite true? (genuine question, what am I missing?)

I think these kinds of optimizations make our ecosystem messy and make it harder for new developers to understand what's going on. Publishing another about message costs what, a few hundred bytes? But it comes at the cost of every SSB app (that implements this feature) having to check two different message types every time you need to display a profile image. In some databases that's now two different tables you need to read, two different model objects you need to instantiate and then reconcile. Balance this with the fact that most feeds will probably never have more than a few thousand block messages, so that's on the order of 1MB total of disk space that this optimization would save for a user over their lifetime. That small amount of disk space isn't worth the complexity cost to me.

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
Join Scuttlebutt now