You are reading content from Scuttlebutt
Feed of @Trigger Warning
@Trigger Warning
Followed @Anders
@Trigger Warning
Voted For the interested; [Tamitha Skov](https://www.youtube.com/watch?v=dWwCxWEK
@Trigger Warning
Followed @Gordon
@Trigger Warning
Voted Some things seems to be happening over at #sunrise-choir https://github.com
@Trigger Warning
Voted @Dominic stated: "But if you both lower your price, then consumers don't b
@Trigger Warning
Voted [@CustomDesigned](@iOyfRmje5LFAErH7M3faTLNMQUTXCnjECbLtniVJ478=.ed25519) it
@Trigger Warning
Voted [@CustomDesigned](@iOyfRmje5LFAErH7M3faTLNMQUTXCnjECbLtniVJ478=.ed25519)
@Trigger Warning
Voted It has been a week, hope your feeling better! Please let me share a bit of
@Trigger Warning
Re: %UADLZmssb

I am mainly concerned with users of #ssb being wrongly accused by legal systems of "publishing" illegal content, whether child porn or copyrighted material in the US - when their node (perhaps a pub) is simply caching content from a bad actor. I wish there was a way to "pre-educate" law enforcement: with SSB, the originator of illegal content is not necessarily (or even likely) the owner of the device on which it is found in ~/.ssb/blobs/.

I think that only blobs are a concern, as messages are small enough to be considered "excerpts" for copyright purposes and too small for erotic pictures. However, illegal content could be published encrypted on public servers, and links with a decryption key posted on SSB.

On my project list is a separate CLI tool to show which feeds are responsible for which blobs (first mention is the best responsibility algorithm I've thought of). But this could cause problems if e.g. the user blocks a bad actor, but the software doesn't remove blobs mentioned by the bad actor. Then, some other feed with a message saying something like, "I'm pretty sure %foobarbaz... is illegal" would get blamed.

I also envision a separate CLI tool to delete feeds (as proof of concept for eventual inclusion in clients). It would leave framing and feed id, but content and links would be cleared in place in log.offset, referenced blobs deleted, and message type set to "deleted" or "blocked". The signature would be invalid (and should be cleared as well), but that should not stop the rest of the system from working. Following the size fields to scan log.offset would continue to work as before. Then the log can be compressed and offset indexes rebuilt in a batch process.

So, CLI tools:

ssb blame [HASH ...]
ssb rmfeed @feed_id ...
ssb compress

@Trigger Warning
Voted ## 0.1811.28-beta * Fix Wi-Fi discovery and sync on some devices ([see det

Show whole feed
Join Scuttlebutt now