You are reading content from Scuttlebutt
@Dominic %GuHCd0gTrobTyVyhWVdW395umVcNJGFqGKZH3WEHyGQ=.sha256
Re: %oxtXLx0Ad

@keks yes to another call. Appologies to including implementation specific details, but that is just me thinking out loud. I think the simplest implementation is the ultimate goal, so we need to think about that.

trusted: there is another implementation to this word, it's about how much effort you put into auditing something. By removing the need manage the connection to the local sbot from the plugin, then all that stuff becomes unnecessary, and just finding it there is suspucious. If the plugin connects to the sbot, identifies itself, and then dynamically announces it's api... that is a lot more to audit. The sbot is "trusted code" because we are familiar with it's internals, we wrote it or audited it. A plugin is untrusted code until we read it and decide it's safe... so even without sandboxes we've reduced the amount of untrusted code, in the sense of the code we need to read.

I'm influenced here by thoughts on security after 10 years of qmail (main take away being, reduce security bugs by reducing bugs, and the main way to do that is by reducing lines of code)

Join Scuttlebutt now