ZeroNet Blogs

Static ZeroNet blogs mirror

Adding images to posts

- Posted in Geekless.Blog by with comments

Just noticed, that adding images on ZeroBlog can be somewhat unobvious for new users.

1. Enter the post editing mode. 2. Press Enter to get to an empty line. 3. The blue plus sign appears. Press it. add-image-1.png (477x213) 4. Press the rightmost icon on the bar to add an image. add-image-2.png

I received a mail today from a person who wrote he or she registered a .bit domain for me. I am grateful to that person for wanting to help, but I have to refuse that gift.

I am pretty okay with the usage of the plain cryptographic keys for addressing sites, and I'm not going to use the Namecoin domains for my sites. Actually, the cryptographic keys are the only sound way to address sites in ZeroNet now, and Namecoin domains don't seem reliable for me at all.

However, the mail made me think about the potential abuse of the names. So I have to make a statement:

I've never registered and not going to register any .bit domains for my ZeroNet sites. All my zites are available by their plain cryptographic addresses only. And even if some of them are available by .bit domains, it is not me who owns the domains.

Rest in Peace Roman Karshiev

- Posted in Geekless.Blog by with comments

Roman Karshiev, one of the most active ZeroNet users and activists, known as balancer73@zeroid.bit, has passed away.

He was the owner of a lot of zites and also ran a popular Russian forum in the Clearnet. Here are his zites (and maybe I missed some):



Blogs (En):

Blogs (Ru):

Clearnet sites:

He believed in the future of the P2P technologies, that can bring more freedom to the people all over the world. And in particular, he was a great Zeronet promoter. He was a nice person as well. His enthusiasm and optimism were really inspiring for people around.

He criticized some P2P solutions for being too unreliable, and he saw a great advantage of ZeroNet in being able to keep the data forever. No matter, how many years passed, in which planet people live, and what kind of internet they use, zites will probably still able to work fine.

"When I die, my ZeroNet blog will be the only digital trace of mine, that doesn't depend on any 3rd party services, companies or persons, and will have been surviving for many years. If my work is worthy of something, people will keep, read and use my zites." - that is what he and I both agreed in. When we talked about ZeroNet, we both often admired that feature. But I couldn't even imagine that this idea would become the real fact so soon.

A few months ago, Roman started posting memories and stories in his blogs. He seemed to have a premonition and tried to write down as much as possible. One of his blogs has a subtitle: Буду записывать, пока ещё память жива — "I'm going to write, while my memory is alive yet". Now those words sound so... unspeakably sad.

I only hope, his private keys will not fall into the wrong hands, and his zites'll keep running. Unfortunately, ZeroNet doesn't yet have the archiving/snapshot feature implemented, so the content is still vulnerable for being erased by a person, who stole the private key.

Aged 45. He left a wife and 2 young children. And so many things left unfinished.

Rest in Peace, Roman. We miss you so much.

roman-karshiev.jpg (400x400)


- Posted in Geekless.Blog by with comments

LuaJIT написан гением. Mike Pall практически на коленке реализовал трассирующий JIT-компилятор, который в тестах производительности либо рвёт, либо идёт ноздря в ноздрю с продуктом крутой гигантской корпорации — V8. Я думаю, сравнивать реализации JS и Lua вполне уместно, поскольку оба имеют очень похожую систему типов, набор фич и область применения. JIT-компилятор при генерации кода у обоих языков решает примерно одни и те же задачи.

В отдельных случаях скорость исполнения кода в LuaJIT приближается к скорости кода на Си, скомпилированного без оптимизаций. Под «приближается» я имею в виду: отстаёт всего в несколько раз, а не на два порядка, как это обычно. И это динамически типизированный скриптовый язык.

Никакие Перлы, Руби, Питоны и PHP и близко не лежали. Питоновский pypy умеет только жрать память и тормозить после стольких человеко-лет разработки. Про ванильный python в разговоре о производительности вспоминать вообще неприлично.

Только одна вещь меня расстраивает в LuaJIT — это Lua. Почти всё можно простить языку, но адресация массивов с единицы — такого прощать нельзя.

Очень хочется взять сорцы LuaJIT и перепилить их под компиляцию JavaScript. Можно будет встраивать этот интерпретатор JS даже в утюги, и такой утюг будет летать. Это будет бомба, котаны!

Не знаю, доберусь когда-нибудь ли я до этого, но руки чешутся очень. Напишите в комментариях, если у вас тоже. Может быть, совместно что-то выгорит.

Some user ID statistics

- Posted in Geekless.Blog by with comments

At the moment, I have 545 zites hosted on my computer:

$ find * -maxdepth 0 -type d | wc -l

So I decided to get some stats.

I extracted user names from content.json files:

$ find . -name 'content.json' | xargs grep -h -o '"cert_user_id":.*' | grep -o '[^"]*@[^"]*' > /tmp/all_nicknames

Total count is 70950:

$ wc -l /tmp/all_nicknames

That is how many times different users are logged in on different zites.

Okay, how about counting only the unique entries? 31256 unique users in total:

$ sort /tmp/all_nicknames | uniq > /tmp/uniq_nicknames
$ wc -l /tmp/uniq_nicknames

Let's count, how much different ID providers are popular:

$ grep -o '@.*' /tmp/uniq_nicknames | sort | uniq -c | sort -nr
  29314 @zeroid.bit
    741 @zv.anonymous
    508 @millchan
    242 @ifs.anonymous
    195 @kaffie.bit
    104 @zeroverse.bit
     66 @cryptoid.bit
     53 @0ch.anonymous
     26 @nobody
      4 @kxoid.bit
      2 @zeropolska.bit
      1 @sorasumi.bit

Top 50 active users by the number of zites they use:

$ sort /tmp/all_nicknames | uniq -c | sort -nr | head -50
     92 ssdifnskdjfnsdjk@zeroid.bit
     81 balancer73@zeroid.bit
     77 krixano@zeroid.bit
     72 gitcenter@zeroid.bit
     68 binchan2@zeroid.bit
     65 geekless@zeroid.bit
     60 putsan@zeroid.bit
     58 kaffie@zeroid.bit
     57 glightstar@zeroid.bit
     55 zalex@zeroid.bit
     50 anonymouslogin@zeroid.bit
     47 styromaniac@zeroid.bit
     44 sirenyc@zeroid.bit
     42 ulrichard@zeroid.bit
     42 polar@zeroid.bit
     42 piloth@zeroid.bit
     42 eibriel@zeroid.bit
     41 trooper@zeroid.bit
     40 weakish@zeroid.bit
     39 thunder33345@zeroid.bit
     39 qiwi@zeroid.bit
     39 muja@zeroid.bit
     39 erkan@zeroid.bit
     39 atheist@zeroid.bit
     38 caryoscelus@zeroid.bit
     38 blurhy@zeroid.bit
     37 tangdou@zeroid.bit
     37 p2p@zeroid.bit
     37 nippletwister@zeroid.bit
     36 musickiller@zeroid.bit
     36 jad@zeroid.bit
     35 htgozn@zeroid.bit
     35 frayoshi@zeroid.bit
     34 zerolstn@zeroid.bit
     34 ks@zeroid.bit
     33 yilmazerkan@zeroverse.bit
     33 wanditoast@zeroid.bit
     33 schiz0@zeroid.bit
     33 l8@zeroid.bit
     33 aimaster@zeroid.bit
     32 nofish@zeroid.bit
     32 booma@zeroid.bit
     30 nishikinomaki@zeroid.bit
     30 nekocross@zeroid.bit
     30 mkg20001@zeroid.bit
     30 cer@zeroid.bit
     30 beelzebub@zeroid.bit
     30 a7oiz@zeroid.bit
     29 scrub@zeroid.bit
     29 nekololi@zeroid.bit

Top 50 active users of non-default ID providers:

$ grep -v '@zeroid.bit' /tmp/all_nicknames | sort | uniq -c | sort -nr | head -50
     33 yilmazerkan@zeroverse.bit
     10 inner-iframe@zv.anonymous
      8 glightstar@kaffie.bit
      5 zeroali@kaffie.bit
      4 zero@kaffie.bit
      4 v0net@cryptoid.bit
      4 shouko@kaffie.bit
      4 sayo@kaffie.bit
      4 redacted@zeroverse.bit
      4 mydf@zeroverse.bit
      4 love is love@kaffie.bit
      4 iforgotmyusernam@zeroverse.bit
      4 anoni2p@zeroverse.bit
      3 zeroday@zeroverse.bit
      3 yinyue@zeroverse.bit
      3 waterfire@kaffie.bit
      3 wanditoast@kaffie.bit
      3 user0@kaffie.bit
      3 tomato@zeroverse.bit
      3 skwerlman@kaffie.bit
      3 secc@zeroverse.bit
      3 rJZLkfoUeskWN@ifs.anonymous
      3 repository@kaffie.bit
      3 Q5eqdoI7jBend@ifs.anonymous
      3 priviet@zeroverse.bit
      3 polar@kaffie.bit
      3 phantom@cryptoid.bit
      3 nofish@kaffie.bit
      3 misaka@kaffie.bit
      3 linuxguy@zeroverse.bit
      3 lily@zeroverse.bit
      3 krixano@cryptoid.bit
      3 @kaffie.bit
      3 iWsOx4FYrGECf@ifs.anonymous
      3 ivesen@kaffie.bit
      3 gt@zeroverse.bit
      3 fengyun007@kaffie.bit
      3 dfgdf@kaffie.bit
      3 comeon@kaffie.bit
      3 bSKC5cV07XI15@ifs.anonymous
      3 botkek001@zeroverse.bit
      3 a@zeroverse.bit
      3 1HNdbW1A9dgLH@kaffie.bit
      3 0penworld@zeroverse.bit
      2 zyo@kaffie.bit
      2 zenplayer@kaffie.bit
      2 Xme4c0hLbApjv@ifs.anonymous
      2 xijinping@zeroverse.bit
      2 xAPMjs9kQtoC7@ifs.anonymous
      2 waxmiguel@kaffie.bit

How many users use 10 or more zites:

$ sort /tmp/all_nicknames | uniq -c | sed 's/^ *//' | awk '{ if ($1 >= 10) print $2 }' | wc -l

How many users use 5 or more zites:

$ sort /tmp/all_nicknames | uniq -c | sed 's/^ *//' | awk '{ if ($1 >= 5) print $2 }' | wc -l

A site owner has:

  • The private key.

  • The content she wants to sign and publish.

She calculates the public key from the private key and then calculates the hash sum of it. The hash sum is what we know as a site address, such as 1BLoGBTid3NhGu8ts3fAfHJprnbrH3wfTV.

Using the private key and the content, she calculates the sign. We can consider the sign as a cryptographic mix of the private key and the content. We can't extract the private key back from it, but, with the content provided, we can mix it futher and produce the same public key, that can be calculated from the private key itself.

So, the site owner publishes the data:

  • The site address, i.e. the hash sum of the public key.

  • The sign.

  • The content.

When a visitor gets to the site, he verifies the data provided. He applies the content to the sign and calculates the public key. Then he calculates the hash sum and compares it to the site address. If they are equal the verification is successful, and he can be sure the content belongs to the site owner. If not, either the data was corrupted during transfer, or someone tries to fool him, providing a modified, unsigned content.

              SITE OWNER                |  NETWORK  |               VISITOR
                                        |           |
          +----> public key -> hash sum --------------------------------------> should be queal
          |                             |           |                           ^
private key -+-> sign --------------------------------> public key -> hash sum -+
                 ^                      |           |   ^
content ---------+--------------------------------------+---------------------> content is verified
                                        |           |

About user verification process

- Posted in Geekless.Blog by with comments

Daniell Mesquita wrote a post at ZeroMedium: (part 2) How do I envision ZeroNet to be ready for mass of users. I posted a comment about the user ID verification system he proposed, but it turned out ZeroMedium had no support for markdown in comments, nor it allowed editing them. So I repost it here.

ZeroID should have a user verification feature, in which Nofish (verified user on Generation 1), can verify other users (they will be also Generation 1). Then when the Generation 1 users (except Nofish) verifies other users, they will be Generation 2, and following at this form.

I don't think it's an option.

  1. Any verification system is a kind of 3rd-party censorship, and ZeroNet is totally about not having any 3rd-party censorship and moderation ever possible in a forced way. It is up to the user to decide, what content she wants to see and what she doesn't.

  2. Nofish, or any other trusted user, has no actual knowledge about users he verifies. Nothing can prevent a spammer from sending humanish-looking automated verification requests and getting lots of new accounts.

  3. Speaking about it, a manual verification system cannot scale and can be easily DoSed.

  4. Generation 1, 2 and so on actually look like we have first-class and second-class citizens. The system is not only unfriendly to new users, but also looks really scaring. I believe, many people will wonder: "Do you develop some kind of nazism there?"

An idea just came to my mind. I recently posted the proposal for 3-way white/gray/black-list-driven processing of user data. If it will be implemented, we can also add more ranking algorithms, not just pretty random one, I proposed there. So, we can require some proof-of-work from a gray user to recieve, store and dispatch her files.

It is calculated as p = pow(N, user_cert), with N included in the content.json - I mean, it is pow for your ID, not for your data, so you don't have to recalculate it on every message. N can be changed at any time, so you can run mining on your computer and use your ID at the same time. While you have a poor PoW, you are probably considered as a spammer by the most hosts, but getting better and better PoW allows you to become trusted enough for most of the network.

Since a pow is applied to an ID, the network can require a costly enough pow, without being to laggy for an end user. (If you ever try sending a large message via BitMessage - it takes veeeery looooong time, since pow is calculated for all the data). If you're a real user, you can even pay some money to a mining farm to get nice pow. And if you're a spammer, you just have no profit, paying for each new short-living ID. Probably, hosts can guess the optimal pow limit, based on typical pow values of whitelisted users and adjust it dinamically.

В ходе дискуссии с @leftside родилась идея: основанный на криптографии контроль доступа к постам блога.

Если у меня будет время, попытаюсь реализовать в ZeroBlog++.

Как это выглядит для пользователя:

При редактировании поста автор блога может указать его видимость: публичная или ограниченная.

Если он выбрал ограниченную видимость, он может указать список user ID-ов, которые могут видеть пост. Если он никого не указал, пост видит только он сам.

Обойти эти права доступа невозможно: посты с ограниченной вимостью зашифрованы.

Под капотом:

Куча криптографии, которую мне лень описывать. Самое важное, что для пользователя всё это будет не видно, пользователь не обязан ичего знать о криптографии.

Отдельные проблемы, которые могут потребовать больше времени, чем само шифрование постов:

  • Изображения и другие аттачи к посту также необходимо шифровать.

  • Для удобства потребуется интерфейс управления группами пользователей.

  • Комментарии к шифрованным постам должны быть либо запрещены (плохо), либо также быть шифрованы (требуется реализация шифрованного чата).


A new idea: access control for blog posts

During the discussion with @leftside, an idea came to my mind: cryptography-based access control for posts in a blog.

I'll try to implement it in ZeroBlog++, if I have enough time.

How it looks to the user:

When editing a post, the blog's author can choose the post's visibility: public or restricted.

If she choose the restricted one, she is able to specify user IDs, who are able to see the post. If she didn't specify any user IDs, it is only her who is able to see the post.

It is not possible to bypass the access control, since the restricted posts are encrypted.

Under the hood:

There are lots of cryptography there, and I'm too lazy to explain it here in details. The most important thing is that it adds no complication to the user experience, the user don't have to know anything about cryptography.

Some problems, that can take more time than the implementation of the feature itself:

  • Images ang other attaches should be encrypted as well.

  • The UI to control user groups is required for better experience.

  • Comments for restricted posts should be either disabled (bad thing!) or encrypted as well (a lot of work to implement a fully-functional encrypted chat).

Только что в блоге @nofish появился анонс свежих изменений:

Shared tracker list between users:

New tracker IPs automatically discovered from other users to reduce centralization and avoid the blocking of the trackers.

To start new tracker: Enable the Bootstrapper plugin with opened port, then it will automatically share your client's ip with other users as a possible tracker. (It's only recommended to do this if you have static ip and planning to keep your client running 24/7)

Only the working trackers (successful result in past hour) are shared with other peers and the discovery request done in every 5 minutes until your client found 5 working shared trackers. This feature is also got limited to zero:// trackers only as it more suited for ZeroNet, because it allows multiple sites announce in same request and the storage of .onion addresses.

Итак, теперь узлы сети могут сами находить новые трекеры — пока только трекеры с публичным IP, но я думаю, что доработка для трекеров на onion-адресах будет не сложной. ZeroNet становится всё более отказоустойчивой и независимой.

В самом начале своего существования сеть работала через torrent-трекеры и была полностью зависима от них. Потом появились собственные zero-трекеры, способные работать как через IP, так и через Tor. Также появился собственный механизм обмена пирами.

В прошлом месяце в ZeroNet была добавлена возможность вручную добавлять пиры для зайтов.

И вот теперь пиры могут обмениваться также и списками трекеров.

Это означает, что теперь бутстрап-узлом при запуске нового узла может быть абсолютно любой узел сети. Достаточно указать известный узел в качестве пира, и затем ZeroNet найдёт с его помощью доступные трекеры и выйдет на полностью рабочий режим.

Ранее я уже писал о проблеме малого количестве трекеров в ZeroNet. К сожалению, при работе в режиме Tor: Always проблема усугубляется.

Вот список трекеров, используемых сетью по умолчанию в настоящий момент:

        trackers = [
            "zero://",  # US/NY
            "udp://",  # DE
            "udp://",  # NL
            "udp://",  # US/LA
            "",  # CN
            "",  # DE
            ""  # BY

Разберёмся, что тут к чему.

  • Адреса, начинающиеся на udp:// — это BitTorrent-трекеры, работающие по UDP. При работе через Tor они недоступны. Совсем.
  • Адреса, начинающиеся на http:// — это BitTorrent-трекеры, работающие по HTTP. Мы можем получить от них адреса пиров в клирнете, но не можем через них анонсировать onion-адреса. BitTorrent-трекер увидит и запомнит лишь IP-адрес exit-ноды Tor-а, который для входящих подключений бесполезен. Трекер ничего не знает про Tor.
  • Адреса, начинающиеся на zero:// — это собственные трекеры ZeroNet, работающие по внутрисетевому протоколу. Трекеры ZeroNet умеют работать как с IP-адресами, так и с onion-адресами пиров.

Как видим, собственных трекеров сети всего два. Один из них расположен в клирнете, а другой — в Tor.

Именно на этих двух трекерах и держится связность сети в режиме Tor: Always. Отключение этих узлов приведёт к невозможности пользоваться сетью в анонимном режиме.

Пока сохраняются BitTorrent-трекеры, и есть узлы сети на IP-адресах, к которым мы можем открыть входящие соединения, проблема может быть не критичной, тем не менее, это принципиальная проблема. Если завтра все участники сети решат пользоваться сетью без разглашения своих IP, то именно эти два узла станут самой уязвимой точкой отказа.

Как решать эту проблему? В три этапа:

  1. Поднимать новые ZeroNet-трекеры на своих компьютерах.
  2. Публиковать их onion-адреса и призывать других участников сети пользоваться ими, рассказывая, почему и зачем это нужно.
  3. Разрабатывать и внедрять в движок ZN новые механизмы анаонсирования узлов, такие как DHT или автоматический внутрисетевой поиск трекеров.

Что касается пункта 1, внутрисетевой трекер реализуется плагином Bootstrapper, поставляющимся с ZeroNet. Плагин по умолчанию отключен, и документации на него никакой нет; вся документация — только его исходники. Насколько я понимаю, два трекера из списка выше работают именно через этот плагин. Сам я еще не разбирался с тем, как там что.

Если я правильно понимаю, достаточно запустить ноду ZeroNet с включенным плагином, чтобы она слушала порт на локальном интерфейсе, и затем средствами Tor поднять hidden service с фиксированным адресом, который будет проксировать входящие подключения на порт ZeroNet. Но это пока теоретические соображения.