>>3102
Fair enough, guess I suck cocks and can't read.
>1. relatively safe from the feds for everyone using it (ie you won't get jailed for what you post)
While a worthwhile goal, I think it's bad to assume feds need some kind of post directly linking to a person to jail them. Laws anywhere in the world are grey enough that an adversary the size of a government can just do some psyops and creative interpretation, no need for material evidence.
>eliminating metadata and relying on anonymous transport, and perhaps deniable encryption of data
Now this I can get behind. Anonymous transport is probably outside of the scope of such a project. Consider I2P and Tor. While, in theory, I2P glows less and has less identifiable traffic patterns when looking at the network from outside, there are a lot less people using it. So you can't necessarily tell what resources people are connecting to, but it's easier to make a complete map of users around the world than it is with Tor. An acceptable form of transport could be plain old obfuscation, innocuous posts on popular resources with media containing the information you really want to transfer. This solution also crosses over with deniable encryption. As for metadata, any P2P solution inevitably generates it just because you need to connect to your peers and they'd have no real incentive to erase it. Starting from the project inception, there's also the problem of git itself having built-in metadata. Some of it is needed for your repo to properly function, but most of it is not good for anon. You could say that there's no need to keep precise times of commits, just to make sure the tree of commits is chronologically accurate.
>destruction resistant (can't be taken down, from inside or outside)
This is also something I don't agree with. Can't be taken down from inside is achievable, with enough gatekeeping and warding off the inevitable infighting and faggotry that seeps in. But there is no need for firm opposition against an enemy that overwhelms you with money, resources, human resources and (supposedly) public opinion. If your idea does end up becoming reliably decentralized, why not simply split the network based on areas of jurisdiction? Node A is located in the US, node B is located in Romania. Firewalls of both are configured such as they're unreachable from the host country to avoid obvious liability. It's illegal to talk about subject X in node A's jurisdiction, so you host it on node B and use an anonymous or just obfuscating network protocol to access it from node A should you want to read it, and in reverse. The greatest weapon in fighting deplatforming on the Internet in current year is bureaucratic red tape. The more of it you need to go through and the smaller the targets, the less effort will be expelled toward taking you down (in theory).
>I am going to implement it how ever long it takes. Call me ideaguy or what ever, at least I am doing something
Well, then I wish you good luck. Hopefully you do implement something, even if it's 5% of what you laid out. Ideaguys, as the name implies, only come up with ideas and don't do any actual coding.
>federation never works only a tiny portion of users selfhosts and they are very easy to take down, just like the webring
I think both a P2P network and a federated one can coexist, if you think my splitting by jurisdiction idea isn't full of shit.
>Mod combination
Here's what I'm personally concerned with. Say you and I are having a conversation inside some thread. I have my mod list, you have yours and they are distinct with some overlap. Now a third person joins, them also having a somewhat distinct mod list. We start talking and posts start disappearing due to filters not being uniform, so now there's a better chance of a potentially good conversation devolving into useless metafaggotry about muh filters and muh mods. It would make more sense to have OP designate mods for their own threads. Solves the hypothetical I demonstrated and also allows you to filter threads based on mod tags.