ZeroNet Blogs

Static ZeroNet blogs mirror

NixOS torrent [19w]

- Posted in hexkey's zite by with comments

I made a torrent for the latest version of NixOS. Give it a bit o' love, if you please :)

Life happened again [57w]

- Posted in hexkey's zite by with comments

Isn't it funny how that happens? -_-

But anyway: I haven't given up on this blog just yet. Once I find more stuff to put here I will do so.

Not much else to say for now. Cya around!! ^_^

Edit: Just realized my toc is borked up. I'll fix that at some point.

Life happened again [42w]

- Posted in hexkey's zite by with comments

Isn't it funny how that happens? -_-

But anyway: I haven't given up on this blog just yet. Once I find more stuff to put here I will do so.

Not much else to say for now. Cya around!! ^_^

Giving LBRY a try [390w]

- Posted in hexkey's zite by with comments

If you haven't given LBRY a spin yet, here's a quick summary:

It's a decentralized content distribution network much like Bittorrent. Unlike Bittorrent, though, a currency system is involved--LBRY credits. This allows content creators to (optionally) charge for their work. The minimum charge is 0.1 LBRY (about $0.06 or €0.05 at time of writing), although prices will vary (obviously).

We've had attempts at a decentralized/payment-incentivized content network before. Joystream appears to be a working model, but it has a few shortcomings in comparison: mostly the two facts that there is no equivalent of LBRY's identity model (meaning that the whole content producer/ consumer dynamic doesn't exist) and that it's closed source.

LBRY itself isn't complete yet--for example, I don't think you can get compensated for hosting content yet--but the GUI version is functional.

it's pretty shinny

Not only that, but the developers are approaching it in a fairly decent manner.

When it comes to creating a product heavily based around user-produced content, three things matter: the backend, the frontend, and the users/content. The first two are often blent together, but it's best to view them as separate concerns. Personally, I prefer the 'If you build it, they will come' approach--the idea that when developing, the backend/frontend should be priority one--and that the users and content will naturally arrive if the platform is well-made.

There's a 'stronger' version of this view that basically states that 'if you build it [the backend], they [frontend developers] will come', with the version above being an implied sequel of sorts. I don't mind this version for certain things (depends on the project), but social platforms that only attract developers and similar people don't always become quite as successful as they otherwise could.

The LBRY devs have given more attention to the userbase concern than I would've expected from a project this technical; I'd say the screenshot above shows that pretty well. I can't guess at LBRY's future with any huge degree of accuracy, but I think that it has an excellent shot at gaining significant prominence.

If you wanna give it a spin, please do use my referral link--we both get a little something out of that :)


Sorry for being away for awhile--life and stuff happened.

But I did come across (and finally try) NixOS, a new-ish Linux distro with some pretty cool features. I'll let a snippet of the distrowatch page do the talking:

In NixOS, the entire operating system, including the kernel, applications, system packages and configuration files, are built by the Nix package manager. Nix stores all packages in isolation from each other; as a result there are no /bin, /sbin, /lib or /usr directories and all packages are kept in /nix/store instead. Other innovative features of NixOS include reliable upgrades, rollbacks, reproducible system configurations, source-based model with binaries, and multi-user package management.

Installation was pretty painless (on a VM at least), and an instruction manual is even included. The site is here if you want to give it a spin.

I swear, this blog (zero-blog? zlog?) is becoming a 'hey, look at this thing I found' list. I don't think I actually mind that, though.

But anyway, DNSSB is a DNS system based off Secure Scuttle Butt (stop laughing). It's an append-only cryptographically secure gossiping protocol, which makes it ideal for a drop-in twitter replacement, among other things. Read more about the mini social network built around it here, and more about the concepts behind it here. It's a fairly neat read, and I'd highly recommend it.

I just stumbled across a DNS system called dename, which (if it works) could offer the same functionality as Namecoin--without a blockchain. Yes, really.

I've come across attempts like this before--but the only reasonable one I can recall is DJDNS, which appears to be dead in the water.

Dename's consensus methodology requires only one 'correct' server to be contactable, all others can be compromised and it will still function. This property is also a part of Riffle--a new project by MIT designed to make onion routing more both faster and more secure.

All three look like promising potential solutions to our DNS woes, and I think I might try messing around with them in the near future.

I have keys now [198w]

- Posted in hexkey's zite by with comments

I've made myself some keys for signing things. One is an offline only key (11A3490E), which I will use only for managing my other keys, and the other (7A8ED964) will be my main key. I've used the offline one to sign both the my main key and its SHA3-512 checksum, and have put all relevant files here:

Main public key

SHA3-512 of the key (for verification)

Offline key (for verifying the main key only)

Offline key's signature of the main key and of the above hash

Again, I will be using the offline key only for managing other keys, the main one (7A8ED964) will be used for everything else.

I don't know if the lengths I went to were too excessive (or perhaps not excessive enough), but I'm fairly sure my arrangement is alright. Please let me know if you have noticed a mistake, or if you want to sign keys.

Edit: made my main key available here for convenience.

The stability of Zeronet [804w]

- Posted in hexkey's zite by with comments

A day or two ago, someone on the forums brought up concerns over Zeronet's resistance to attacks and takedowns, specifically regarding its reliance on trackers. My original response is still there (quoted in somebody else's comment), but I've also moved it here for two reasons: so that I can elaborate on it, and to save precious space on Zerotalk. Here it is:

Okay. I have a few things to say.

First: There is no such thing as 'safe', only safer. The same goes for 'uncensorable' and other similar words. Focusing only on the scariest sounding scenarios is flawed thinking (like how some people are scared of being killed by lightning--despite stroke and heart disease being thousands of times more common). If you are concerned, Analyze and inspect the possibilities, but keep yourself grounded in reality.

Piggybacking off the torrent infrastructure eliminates a much more concerning what-if situation: 'what if we were using a custom zeronet-only tracking system and most of it was taken down?' Instead, everyone who keeps torrent trackers online is also keeping Zeronet online, regardless of if they even know that Zeronet exists.

There are a lot of trackers in operation, some in countries that are much less vulnerable than others. Technically, this kind of doomsday situation could still happen, and a worldwide shutdown could be put in place--But It would be much more impractical. Not only would locating and catching them all spread this hypothetical enemy's resources very thin (and spark worldwide outrage that they would prefer not to deal with), but it would buy everyone else time to put up even more. Trackers are targets, but they are targets with a massive social shield in front of them.

But again, that's an extreme hypothetical situation. It's best to put effort into what's likely instead of wasting it on things that might never happen. Here are a few relevant things:

1. If possible, donate to help develop DHT Functionality.

2. If you can, actually help develop it (or recruit someone that can help).

3. Same for i2p support.

4. Keep tabs on what trackers are up (but not too obsessively, because we already have people for that).

5. Learn Ham radio. Not as capable, but much more reliable communication.

And any other suggestions anyone might have.

More details:

Here's a rough rundown of the main methods for locating nodes in a p2p network (these definitions are a bit rough, but good enough for this list).

Trackers are relatively easy to set up (and easy for peers to work with), but expensive to keep running under the load of bazillions of queries per day--they are also the most centralized option, making them the most vulnerable. Workarounds include having more of them, using tracker exchange (sometimes supported), and only relying on them when necessary.

DHT is much more scalable, but still requires a known address to enter the network--and peers are less likely to be online as continuously as trackers. Some workarounds are including a list of peers in the installation, and having one or more servers that can distribute active peer lists (This shares some weakness with trackers though).

The third option isn't too common: Address surveying, or randomly scanning address until finding one which offers the service you're looking for. Unlike the others, this one is guaranteed to succeed at some point--however, the internet is huge, so it won't always be practical. Also, randomly scanning thousands of ports is bound to piss some people off--probably not anybody you want to be dealing with.

Some combination of these will eventually locate one peer, which can then cascade into knowing as many as you need--by more use of these methods, and/or these as well:

Peer exchange: asking already known peers for any other peers they know. Cascades quickly, but not if it can't reach a certain 'critical mass' first (vaguely like if two or more circles of friends have none in common).

Local peer discovery: like address surveying, but much less obnoxious (and only on your local network area). Usefulness roughly depends on the size of said network.

That's all I got for now, but I'll add anything I think of later.

There are some other nice goodies here. Not all of them will apply to Zeronet, but it's still a handy reference if you want to do your own investigating. Also keep in mind that Wikipedia and stackOverflow are always a good first place to look.

Moderation is hard [WIP][1,385w]

- Posted in hexkey's zite by with comments

xkcd #1357

There is an ongoing conversation about how to moderate content on zerotalk. It's proving to be pretty complicated (as it always has been). When trying to balance free expression and quality control, having both is really hard. I've made a list of things that should probably be put into consideration. Keep in mind that this list is not complete or absolute in any way:

Kinds of unwanted Content (UC). These are the ones I can think of right now (most are partly subjective):

  1. Off-topic content: Content that doesn't contribute to the conversation.

  2. Spam: Advertising or endorsing something (free or otherwise), usually irrelevant to the conversation at hand.

  3. 'Swamping': Posting repetitive/ nearly repetitive content in one place.

  4. Offensive content: Text, images, or otherwise. Includes both hate-based content and generally uncivil content.

  5. Harassment: Directed at a specific person.

  6. Targeted Harassment: Content directing others to harass a specific user.

Here are some general approaches (not 'solutions', since no system is perfect):

  1. Centralized moderation: by mod(s) who are self-appointed, elected by a higher level set of users ('sub-moderators'), the common users, or some degree of each.

    1. Mods are given certain abilities, eg deleting posts or hiding posts; flagging users/posts/subsections of site as potentially offensive (for subjective UC), offensive (for less subjectively UC) suspicious, warned (Content source (CS) has been warned of breaking/bending site rules 1+ times), and potentially more.

    2. A 'chain of command'--where power is distributed in a tree-like structure-- is possible.

    3. Relies on good intentions of mod(s) in order to curate / sanitize community and content.

    4. Moderator modification of user content is not possible with ZeroID-like systems--and the ability to delete posts means it is likely unneeded anyway.

  2. Voting systems: posts are up/downvoted based on content.

    1. Less centralized than moderator based systems.

Here are some specific approaches:

  1. Standard Voting System: up/down votes determine content visibility. Allows for a majority of 'good' users to prod a minority of 'bad' users into either leaving the community or changing what they post.

    1. +: Community-based. not enforced by a single entity.

    2. +: Can address all six types listed above to a degree.

    3. +: Can address UC while also promoting higher-quality non-UC.

    4. +: Karma/Reputation systems are possible.

    5. -: Vulnerable to the hivemind/echo chamber effect, where communities selectively filter out content that challenges their existing mindset.

    6. -: Vote manipulation/brigading may be possible (depending on how IDs are distributed and assigned).

    7. -: UC is not actually removed (may/may not be desired depending on circumstances). Different types of UC may demand different courses of action.

  2. Extended voting system: different kinds of votes are available for the different kinds of UC listed above, and up/down votes for each one have different effects.

    1. +: Custom vote behavior may be defined per site owner/user. Examples:

      1. site configured so posts DV'd for quality are collapsed/grayed out.

      2. Posts DV'd for swamping are placed in a separate subsection on the page, and duplicate posts are simply stored once with multiple timestamps (may/may not cause individual posts to no longer be editable, either by necessity or as a penalty).

      3. An owner may configure their site so that a post is automatically removed when it has x% more downvotes in a specific category (eg #4) than compared to other posts across the site, other posts within that specific subsection of the site, other posts by that user, or some combination of those.

      4. A post in one subsection that has been DV'd a lot in a short timespan--but only by users that have a history of abusing their votes/ users that all subscribe to a different subsection--is flagged as 'suspected vote abuse'.

      5. Posts which are DV'd enough have a separate 'visibility rating' adjusted, which affects visibility in one of the ways above (or another way). Users have a 'visibility tolerance' setting they may adjust for one or more of the UC categories.

      6. Posts DV'd enough in one or more UC categories may cause a notification to be sent to a moderator (assuming the site uses moderators) with an attached priority that depends on the amount/rate/types of DVs. A certain priority may send the notification to an admin instead (if the site uses admins).

    2. +: Vote behavior configs could be exportable (eg as json) and shared/modified so site owners don't have to set up their own from scratch.

    3. +: Reduces or eliminates SVS flaws 5 and 6.

    4. +: customizabillity reduces impact of the 'tough luck'/ 'if you don't like it then leave' mindset.

    5. -: Complicated to implement and set up.

    6. -: Understanding what configs are most effective in general/for certain types of sites probably requires a degree in sociology.

    7. -: If the site configuration is encrypted (which might help prevent loophole abuse/ 'working around' the rules), site users may have to simply trust that the site's settings are as the owner says. A possible solution is to have sections of the rules split into different files, so that the owner can reveal select rules by providing salted hashes of them. Still, choosing how much to reveal is difficult.

  3. Web of Trust (WOT) models: Similar to Karma systems. (WIP)

  4. Proof of work (POW) based systems, where certain actions require some amount of computation to complete.

    1. +: Effective against swamping.

    2. +: partly effective against spam and off-topic content.

    3. +: Amount of POW required can be adjusted based on amount of content.

    4. +: Amount of POW required can be adjusted depending on reputation of user or site subsystem.

    5. +: More drastic actions can require greater POW.

    6. +: Actions that affect multiple users/ an entire subsection may require POW from multiple users, with demanded strings encrypted with one or more public keys.

    7. -: Does very little to address any other kinds of UC.

    8. -: Power imbalance: users with more processing power are given more priority (depends on availible POW systems).

    9. -: limits speed of content distribution (undesired in some cases).

Defintions: [1]: UC: unwanted content. [2]: LQC: low quality content. discouraged, but not removed. Exact definition varies per site. opposite of HQC [3]: Subsection: a a specific area of a site (eg a subreddit or similar). May be represented as a merger site. [4]: CS: content source; refrers to users, subsections, and (when applicable) posts. [5]: MVS(u/d): minimal voting system; users up/downvote content based (ideally) on quality. Content is usually not sorted by votes (hence 'minimal'). An extra 'u' refers to systems where only upvotes are available (eg zerochat), and a 'd' is refered to when only downvotes are available (flagging systems are similar, but actual 'downvotes only' systems don't appear to be used). [5]: SVS: standard voting system; like an MVS, but posts may have their order, visibility, and more determined by number of votes. Reddit's SVS is competent, but other versions may be used. [6]: EVS: extended voting system; like the SVS, but multiple categories of votes are available that have different, customizable effects (see below). [7]: Curating - Manually or automatically promoting visibility of / encouraging creation of high quality content, while also doing the reverse for low quality content. [8]: Sanitizing - Manually or automatically removing UC, optionally with a 'holding period' where the removal maybe challenged before becoming permanent. [9]: CaS: curating and sanitizing; also simply known as moderating (this term is discouraged because it can also refer to self-moderation, among other things). [10]: MDR: management dispersion ratio; refers to how concentrated the burden of moderation is. Determined by effort spent (measured as time until a better measure can be found). For example, a system where 10 mods spend half their time managing 100 users (who spend 0% of their time moderating anything) has a ratio of (10*.5)/100=0.05. MDR is not a perfect measure because estimating spent time is difficult, and the time spent will be very unlikely to be constant. [11]: KRS: karma reputation system; vote scores on a user's past posts may influence certain aspects of their account/ future posts.