Closed christianbundy closed 3 years ago
So the clients that I'm aware of that have these features are patchwork (private blocks and follows), and manyverse (private blocks). I'm not keen on figuring out how patchwork does this, so could we maybe refactor this out of manyverse (and into ssb-friends) @staltz ?
I think that any encrypted message (including follows) once decrypted will have .metadata.private attached to msg.value.content or something like that
@arj03 I realized that this issue is a pretty big deal. Currently ssb-friends is blind to private blocks, and if other modules rely on isBlocking
, then private blocks will slip through and the blocked authors appear in the UI, etc.
I also realize that this would require a reindexing in db2-contacts.js
(and flume contacts.js
as well, it seems), because the messages in the log would have to be decrypted.
In the API, here's a rough sketch:
Default case remains the same
ssb.friends.isBlocking({source, dest}, (err, bool) => { })
But then a new opts.details
can be added to get a different result:
ssb.friends.isBlocking({source, dest, details: true}, (err, details) => {
console.log(details); // { response: true, private: false }
})
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?