Secure and Decentralized News Portal based on the ZCash Blockchain

[thoschm]

1. Motivation

Mass access to direct uncensored information and free media coverage of news events has long been an appealing idea. While restriction in freedom of speech may vary from country to country, a completely independent and safe news culture is yet a goal to be attained.

A secure and peer-driven news hub would encourage citizens across the world to engage in real-time issues that really matter to them, both on a local and on a global level, to challenge agenda setting and news presentation in classical media and to become an active part of public opinion shaping.
We propose a platform without censorship (e.g. caused by conflict of interest) to anonymously post news articles by sending a sequence of ZCash transactions to shielded addresses provided by the news page, by that protecting the identity of writers and at the same time making information permanently available through a decentralized structure.

To overcome article size limitations due to the 512-byte memo field length, we also propose a simple tool/library for data fragmentation over a number of n shielded ZCash transactions. We also plan to store media information on IPFS and embed the permanent links into articles published on the ZCash blockchain.

The encoding / decoding scheme will be implemented in a reference library for other people to use. It will also ensure that anybody is able to decode the news articles from the ZCash chain, so there is no SPOF in form of the news-website.

Also, the whole system will be designed in such a way that the news website itself will be fully redundant. We will develop and provide a local toolbox which enables everybody with a ZCash client to fully interact with the on-chain news portal.

2. Technical Approach

The ZCash blockchain supports shielded transaction between shielded addresses based on zero-knowledge proofs [1]. Even though the blockchain itself is available to every peer in the p2p network, shielded transactions are stored in encrypted form. As a consequence, only users having a correct viewing key for the recipient shielded address are able to learn some information about the incoming transfer. Namely, the amount of coins received, and the content of an encrypted memo field passed along with the transaction [2]. However the sending address, as well as the history of the coins sent is not disclosed. The memo field can be specified by the sender of any shielded transaction and enables transfer of a 512-byte payload. We consider the memo field as a secure vehicle for the applications and protocols we build on top.

Architecture Overview

The following will show the high-level architecture of our approach.

Core feature of our approach should be the redundancy of the news portal website itself. It will be merely a frontend to some encrypted area inside the ZCash blockchain. Therefore, we will provide all the tools necessary to interact with the on-chain news portal without ever having to visit the website at all (however, users can visit the website, if they like to and are permitted by their ISP). Just a local ZCash client and our provided tools should be sufficient. Fortunately all this functionality can be implemented using ZCash viewing keys [2]. Also, for convenience, we plan to provide a JSON API for interacting with the website.

Message Fragmentation

Since it is necessary to transmit news articles of arbitrary length, they need to be split and separated into multiple shielded transactions. We propose, and we will implement a procedure that will do the following steps (future changes possible):

• take an input message
• compute a hash of the message
• compress the original message
• create a header containing the message hash, as well as IDs of the following transaction sequence
• append the byte-code of the compressed data in as many 512-byte blocks as necessary along with some sequence indicator or other meta information (to be clarified)
• send the full sequence of 512-byte blocks using the memo fields of shielded transactions

This procedure will enable sending large messages / news articles using the ZCash blockchain.

Transaction Time/Cost Estimation

As the actual amount of transmitted ZEC has no impact on our use-case, only transactions fees will have influence on the total amount of money spent for transmitting news articles.
The time for sending depends on the speed of sending shielded ZCash transactions.

Example:
We take the first chapter of “Alice’s Adventures in Wonderland” with the title “Down the Rabbit-Hole” which consists of 1244 ASCII characters. We execute the following Python script:

import zlib
with open(‘rabbithole.txt’, ‘r’) as f:
	comp = zlib.compress(f.read(), 9)

After this we end up with a 764 byte compressed message length. With an additional 32 byte from the hash computation we get 796 byte. This can be transmitted (including meta information) in 2 ZCash transactions.
Let’s assume a transaction cost of 0.0001 ZEC and an amount of 0.0001 ZEC to be transmitted in every transaction: 2 x 0.0002 ZEC = 0.0004 ZEC
With 1 ZEC equal to $250 USD during time of writing (2018/05/12), sending the message will cost $0.1 USD. With less transactions fees this can be reduced even more, however, $0.1 USD for a highly available and anonymous news article should be quite cost efficient. Also, some (small) cost associated with the service will discourage spam.
With the current ZCash reference implementation (1.1.0) and an Intel i7 4770K CPU we were able to send one transaction every 39 seconds on average. It would therefore take at most 1.5 minutes to send the given text stream. With the upcoming Sapling release, this should be even less of an issue [3].

Media Enrichment

Articles sent via ZCash transactions may contain immutable, permanent IPFS links to media files and syntax/tags for including them in the article; decoded by the website or the provided local toolbox. Storing of media content on IPFS ensures that it is always available and resiliently accessible through P2P network [4]. Like news articles stored on the ZCash blockchain, media files on IPFS will also serve the independent spirit of the world-wide web in full force. We will therefore elaborate procedures to combine IPFS content and ZCash news articles and check security implications of both combined approaches.

Web Frontend / News Portal (https and/or IPFS)

The website should be a “window” to the encrypted news-area within the ZCash blockchain. Therefore, it will be fully redundant, as all the functionality (submitting/reading of articles etc.) should also be possible using the local tools/libraries we provide.
Still, the website should be designed with easy-usage in mind. Blockchains and especially ZCash are a rather complicated matter, therefore, the web interface should enable everybody to access the news articles and easily navigate and wrap all technical details as much as possible.
It will however, contain at least:

• a main page
• a topic selection / search
• a howto-page
• a signature page for posting public keys (details still to be defined)

Technologies will probably include: ZCash, Python, Flask, MySQL, JSON, AWS

Local Frontend / Local Library

If we just rely on a website for user interaction, this is a SPOF and the service could be easily restricted. However, by providing a public toolset for direct ZCash blockchain interaction, the service will be fully decentralized and very hard to limit.
Therefore, together with a local ZCash reference client installation, the toolset should provide all necessary features for submitting and reading articles, but also to sign and verify messages. Our goal is, that the main functionality of the news platform can be used without ever visiting the website for it.
The software will probably be in the form of Python scripts, or executables, this is still to be defined. All tools will be open-source.

Donation / Compensation for Authors

Every author will have a chance to send a private shielded address along with his article to receive donations for his work in a fully anonymous way. Therefore, using ZCash also directly as a payment method for donations, we provide an incentive for high-quality news and we support anonymous authors, since investigative journalism can sometimes be a risky activity.

Trust System

As news articles are submitted in a fully anonymous fashion, a moderation mechanism for articles on the website could be necessary (no moderation of the raw articles stored inside the ZCash chain is possible of course).

We will therefore investigate multiple reward mechanisms on the website:

• A simple up-/down vote mechanism where people can flag inappropriate content
• A pub-key approach, where anonymous authors can sign articles, so the website can verify which articles belong to the same anonymous identity. Based on this, a trust mechanism can be implemented. Example: As apparent from the article signatures, we know that anonymous user Alice has already published 40 news articles. This basically forms a virtual profile and all up-/downvotes are tracked for this profile. If now somebody claims to be Alice but is not in possession of her private key, this will be easily detected.
• A distributed moderation scheme, where peers randomly distributed over the world (or a selected editorial board) will need to vote on messages of new(=untrusted) users to be shown on the page
• An algorithm that automatically filters inadmissible content with human dignity infringing pronouncements (e.g. using pattern matching, topic modelling, AI, …)

The nature and strength of these measures is in our view a major area of research for itself to ensure a balance between freedom of expression, fact based objective content and protection of human dignity.
Example of the optional signing procedure to assign authors a virtual profile for trust-tracking:

Risks and External Dependencies

With today's technical condition of ZCash we see the project as feasible and straightforward. However, since the worldwide mobile internet usage exceeds the desktop one, better usability and scalability will only be achieved if ZCash transactions become mobile and the platform can be used device independently. The ZCash Sapling release will, however, definitely help a lot in this regard.

As stated above, in the second phase we plan to include IPFS into the news platform to be used in a natural way. As user protection is of utmost importance for this project and IPFS was not designed specifically for user privacy and identity protection, there might be some risks about this combination, which need to be evaluated down the road. However, this is not a critical point, as it is not affecting the project in general.

The biggest uncertainty for us is user adoption and the momentum of news/posts that can be published on the platform, as it offers completely anonymous and untraceable (and in the first step uncensored) posts of both text and media content on all possible topics and areas. Depending on usage and experience, both a trust system, additional usability and UI elements need to be added.

3. Team background and qualifications

Thomas S.: M. Sc. in Computer Science (IT-Security, Machine Learning, Neuroinformatics and Cognitive Robotics), 7+ years as software developer, consultant and manager in different positions in Big Data, Machine Learning and Blockchain technologies

Kirill R.: M. Sc. in Financial Mathematics (Insurance and Finance Risk management, ECC, Optimization), 7+ years as developer, actuary, product manager, online marketer, responsible for blockchain strategy in a large German insurance company

We have been dealing with blockchain technologies and cryptocurrency for more than 5 years. As we believe in innovation and disruptive power of technology, both of us quit our permanent jobs in companies and have been working full-time on our own projects since the beginning of the year. Together we have already launched two projects (currently in the live test stadium) - automated arbitrage trading on cryptocurrencies and advanced recurrent neural network architectures for automated trading on crypto exchanges.

Also, we are the authors of www.z-board.net (an anonymous chat platform based on the ZCash blockchain), which we built as a first prototype to tackle our much greater vision that we outlined in the current article.

4. Evaluation Plan

We will provide community updates on regular basis according to our schedule.

However, the best evaluation of this PoC can be done by testing and using our service and by posting articles. We look forward to a detailed feedback on platform functionality and we will gladly include this in our work.

Also, quantitative KPIs for user behavior, such as number of visitors, average time spent on page, number of messages read, number of new articles per week etc. as well as qualitative KPIs such as user feedback on usability and functionality will be defined. We aim at a continuous monitoring concept for future developments.

5. Security Considerations

Our approach will of course use Zcash not solely as a currency. Thanks to decentralization, availability, integrity and most of all the privacy offered by the ZCash infrastructure, it is a secure basis to attack censorship and restrictions in freedom of speech. On the other hand, the solution can only be as secure as the underlying framework.

All tools will be designed in a way that makes the main news website fully redundant, so it cannot be a SPOF. Therefore, only a local ZCash client as well as our provided toolbox will be sufficient to interact with the news platform. We consider this a strong security benefit.

Additionally to the underlying security aspect, it should be an easy to use solution, which can be used by masses not yet been exposed to Blockchain technology.

Implications of using IPFS media embeddings in posts need to be researched separately in phase 2.

6. Schedule

We have divided to full implementation into three stages:

1. Technical core implementation and PoC (3-4 months)

• Message fragmentation over ZCash memo fields
• Publication of “fragmentation-library” as general purpose package for data transfer over multiple ZCash transactions
• Backend development and server platform (e.g. creation of shielded addresses and viewing keys, database work, API, hardening, https, etc.)
• Website frontend for news articles, topics, howto-page, signature-page
• Client tools with UI for reading and composing messages locally (Win, Linux, Mac)
• Procedure for users to sign messages and verify message integrity
• Website JSON API (e.g. retrieve all topics, get all messages, search for articles, etc.)
• Include shielded address for authors to receive donations

2. Usability for authors: advanced editor for writing and posting messages; Usability for readers: trust system and customization options for displaying relevant articles (3-4 months)

• Implementation/parsing of special message tags to display images/links/code etc.
• Provide WYSIWYG editors for authors with embedded article functionality (e.g. images, links, IPFS content)
• Research interoperability and security of IPFS and the news platform and implement if reasonable
• Validate and implement trust system using ECDSA public keys to identify “anonymous virtual user entities” together with a trust-/rating-system on top
• Backend scaling
• Special article search features / sorting
• Social media connections (e.g. Twitter) to post headlines for trusted anonymous users
• Migrating to newer ZCash versions
• Platform and server maintenance
• Security audit
• [Evaluate possibility of a smartphone app]

3. Additional ways to extract and read messages from the blockchain to ensure better accessibility and availability regardless of censorship and local restrictions

• To be defined, but depends on user adoption, previous development and can only be roughly estimated at this point

7. Budget and Justification

Since we have already spent some time on designing and testing the core function, we estimate around $38k to be sufficient to support our development for the first stage in the next three to four months.
To make the proposed solution attractive and user-friendly also for tech-averse users and in order to reach global distribution, we consider the second part as an integral part of this project. In our view, the second stage is also time-consuming and needs ideally permanent maintenance, improvement and development. For this we have to introduce additional developers and we estimate an effort of $42k for 3-4 months of work.
The third stage can be implemented later if we see that the platform finds adoption and is well used. Costs cannot be estimated at this point.

8. Direct Contact

Thomas S.:
e-mail: thomas.schmiedel.at.work/at\gmail.com

Kirill R.:
e-mail: kirill.rubinstein/at\gmail.com

9. References

[1] https://z.cash/technology/zksnarks.html
[2] https://blog.z.cash/viewing-keys-selective-disclosure/
[3] https://medium.com/@_garethtdavies/why-zcash-is-set-to-shine-in-2018-2e8c388f35fd
[4] https://ipfs.io

[zookozcash]

I love this idea! I love it a lot. Zcash is a great substrate for this project, because:

1. You can't give in to the temptation to rely on a SPOF for anything. (Which is, of course, the inevitable eventual downfall of originally well-intentioned platforms like Paypal and Twitter.)
2. You've got payments integrated everywhere already, which will probably prove to be extremely useful for otherwise intractable problems that will arise.
3. There's already a small (but growing), devoted, enthusiastic, friendly, values-oriented community who would be happy to use it and to help buidl it.

[zookozcash]

Minor technical suggestion: use BLAKE2 instead of SHA256 because it is more efficient (especially on ARM64 in phones and embedded devices), invulnerable to length-extension attacks (even though those would probably not arise in this project, but they might), comes with a handy personalization/salting API, and in my humble opinion BLAKE2 is going to last longer than SHA256 is. Also because BLAKE2 is (I think) becoming the most popular hash function among cryptocurrency/decentralized-web/internet-freedom folks (like IPFS, Zcash, Ethereum). BLAKE2 is supported in most of the modern cryptography libraries, is part of GNU coreutils, etc. (Disclosure: I'm one of the co-authors of BLAKE2.) However, SHA256 would almost certainly be safe for this use, will probably last for decades if not centuries, and is widely considered the de facto standard in the greater world outside of cryptocurrencies/decentralized-web/internet-freedom, so it would be okay. But it would be a little slower/more battery-draining on phones.

[zookozcash]

Technical suggestion: use zstd instead of zlib. It is going to be faster and/or have a better compression ratio than zlib for this use, it is very well-maintained, and it supports user-supplied dictionaries. User-supplied dictionaries are a thing that you can ignore for now but in the future you'll be able to use them for truly spectacular improvements in compression, like twice as good as the previous best compression.

NOTE: COMPRESSION IS A SECURITY ISSUE

Compression inherently leaks confidential information about the plaintext. This is a big, complicated topic and there is no good solution to it, and this isn't really the place to try to summarize or explore how it applies, but it is a serious security risk and worth keeping in mind. The reason I bring it up is that better compression ratios can help reduce the risks of this (unfixable) confidentiality leak, when combined with the 511-byte chunking that Zcash already enforces. So, switch to zstd, and then find the settings in zstd which support the tightest compression ratio for natural language text that are acceptably efficient for both compression and decompression on ARM64.

[zancas]

Does this project intend to implement the ZIP 302 (draft proposal)?

https://github.com/zcash/zips/pull/105/files#diff-1bf9e52535f232084bf58e0dc95b8c3b

[thoschm]

First of all: thanks a lot, we really appreciate the valuable feedback.

@zookozcash
msg 1)
We fully agree with your points; ZCash helps to keep promises, which would otherwise be quickly eroded, as can be clearly seen from the examples you named.

msg 2)
For us, it's completely fine to change from SHA256 to BLAKE2 hashing. Together with zstd compression as you suggested, this will make two of the most expensive client-side operations less demanding. Mobile adoption is a big goal for us, so any efficiency improvement will help a lot.

msg 3)
I spent the night researching side-channel attacks (e.g. CRIME for TLS) on the length of encrypted(compressed()) messages, as I wasn't aware of this effect.
I assume that, given 512 byte atomic chunks, very long news articles will be more vulnerable to this kind of analysis and as you say, very good compression parameters will alleviate.
We will therefore use your recommendation for this (zstd + strong parameters + dict), but we definitely keep this point on the radar and we check for options (like randomly injecting high-entropy variable-length sequences into the message, but we have to check).

@zancas
Yes, we can fully support the given ZIP 302 memo field specification.

Best,
Thomas

[zawy12]

If your texts are going to be as short as the Alice in Wonderland example, there probably isn't a standard compression that beats a "roll your own" that begins with something like this:

https://academic.oup.com/comjnl/article-pdf/24/4/324/1039097/240324.pdf

The problem is that standard methods have too much overhead bytes in order to excel at longer texts.

Using my own English look-up table instead of the above (I created it before I knew the above existed), I got the first 1244 characters of Alice In Wonderland down to 529 bytes. The next step would be to send it through a Burrows-Wheeler transform, move-to-front, and then apply algorithmic coding. I was doing this for the memo field but ran out of steam when I realized I needed to redo it in nibbles instead of bytes in order to efficiently use the algorithmic coding. I could get 1250 bytes of English reliably down to 500 bytes. You could write a script to generate look up tables for each language that gets supported.

[thoschm]

Hi @zawy12
Thank you! interesting material and compression advice.
Regarding message length, we have no specific limit in mind. The Alice in Wonderland example might have the size of a quick, informative headline, but we will also support much longer reports/articles.
In any case, as you also recommend, we should provide custom compression dictionaries for the service. Since we also plan to include special message tags for formatting/links/images etc., this totally makes sense.
Consistent with the idea of a pubkey topic on the ZCash chain, where authors can post public keys, we might also create a dictionary topic, that always provides current and signed compression/decompression parameters. Also, the improved compression ratio will counteract the side channel analysis concern.

PS: Pretty sure, using LSTM neural networks for text compression would work amazingly well, have to try this one day.

[zawy12]

I forgot to mention that using only a Burrows-Wheeler transform, move-to-front, and then algorithmic coding on the nibbles, I got the 1244 text down to 733 bytes. This includes the "overhead" bytes.

To create the dictionary for each type of news in this short-text compression, you could get it down to 33%. This isn't very good if most of the texts are going to be over 5k, but if most of them are under 3k, it appears better.

Concerning the dictionary for at least "my" method, you would only need to write a program to blindly convert the equivalent of about 5 books of nibbles into a 300-"word" dictionary based on the probability of nibble sequences and their size. Going to 3000 words (>50 books) is not very beneficial (but this may not apply to whatever kind of dictionary zstd et al need). The paper I referenced describes how the dictionary is created, which is significantly more efficient than Huffman encoding. A simple method applied to nibbles enables it to work on any character encoding.

I am skeptical that a neural or Bayesian net would be very beneficial because the input data is not noisy and we want lossless compression. I would keep it simple.

If the texts average over 5k, then an off-the-shelf compression like zstd seems best for being near optimal and rapid deployment for all languages.

Hushlist is (or is attempting) to include other media in the memo field, risking blockchain bloat.

@zookozcash I don't understand "Compression inherently leaks confidential information about the plaintext." Is there an objective here to keep the text private? If there is, I think a radically different approach would be needed. Other than a previously-shared off-chain decryption key, I can only imagine a solution that requires news to be sent to each recipient's address. The simplest solution would have the decryption key in the satoshis of the coin amount sent. I don't know if a bunch of txns with same coin amount creates a possible attack on zk-snarks. A more complex method would use RSA to include the decryption key as the first bytes of the first memo field, again requiring a message for each recipient. Sending to each recipient puts de-anonymizing power in the central hands of the news source, but having a public resource for acquiring the news address gives similar power to whoever owns or hacks the pubic resource.

[zookozcash]

After thinking more about this, I realized that the part about layering long messages and multimedia on top (which is the part that needs hash functions and compression algorithms that I commented about earlier) isn't actually interesting to me. The reason I'm enthusiastic about this project is just decentralized and payment-integrated social networking, which http://www.z-board.net/ already is! It might be better to iterate on trying to get more and more traction for a twitter-like z-board than to do the engineering work to layer on larger messages and multimedia. For example, maybe publicly-usable gateways (web sites) and clients with good UX is more important than messages > 500 chars. Or maybe a tool for people to cross-post from twitter to z-board and vice versa, or maybe something else that the current users of z-board are wanting and giving it to them will trigger them to pull their friends in.

[thoschm]

Hi @zookozcash,

thank you for your feedback!
We really like the ZCash project and want to build/provide a platform in top, which enables users to interact and communicate with the security benefits that ZCash provides.
Actually, the improvement of z-board to a fully functional twitter-like platform (with client UI, better usabiliy etc.) was second on our list. However, if you estimate, that it will actually be more useful than the news platform, we can easily switch order.
We are also able to successfully implement the twitter-like approach, or z-board 2.0 etc. :)

Here‘s what we can do:
If the twitter-like z-board 2.0 is generally more appealing and the community trusts us, we can realize this (which we can), we can happily submit a rewritten proposal to the second round of the current grant program focusing on exactly this. (we would not like to wait until the next grant program with this, as it would reduce our current time advantage)

Please tell us if this is possible and it‘s not already too late for some changes to our proposal.

Best,
Thomas

[zookozcash]

To be clear, I'm not on the grant committee, so what I say here carries no weight with the grant process other than being an opinion. My question would be: what can you do that will cause http://www.z-board.net to become virally popular?

…

On Mon, May 28, 2018 at 00:30 Thomas Schmiedel ***@***.***> wrote: Hi @zookozcash <https://github.com/zookozcash>, thank you for your feedback! We really like the ZCash project and want to build/provide a platform in top, which enables users to interact and communicate with the security benefits that ZCash provides. Actually, the improvement of z-board to a fully functional twitter-like platform (with client UI, better usabiliy etc.) was second on our list. However, if you estimate, that it will actually be more useful than the news platform, we can easily switch order. We are also able to successfully implement the twitter-like approach, or z-board 2.0 etc. :) Here‘s what we can do: If the twitter-like z-board 2.0 is generally more appealing and the community trusts us, we can realize this (which we can), we can happily submit a rewritten proposal to the second round of the current grant program focusing on exactly this. (we would not like to wait until the next grant program with this, as it would reduce our current time advantage) Please tell us if this is possible and it‘s not already too late for some changes to our proposal. Best, Thomas — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APp9QK7G9J1RC_Nh6NjX7zWXwpKlVQDxks5t26ePgaJpZM4UDaah> .

[thoschm]

Ok, I see.
So let me rephrase my statement from above:
If our approach is generally interesting for the ZCashFoundation, we are basically open to realize the option which is considered more beneficial:

• The secure and anonymous news platform
• Or: a twitter-like z-board 2.0

To answer your question about how to make z-board virally popular, here are some ideas:

Technical improvements:

• A first step would be to give z-board messages more color: emojis, urls, images
• Since ease of use is extremely important, a special platform independent client is necessary (this could be a stand-alone tool, and/or plugins to slack/pidgin and other messengers)
• The virtual profiles that we outlined in the proposal above will be necessary as well, because full anonymity will very likely lead to some inappropriate tweets, which would reduce user experience
• This could be expanded to virtual profile pages containing a collection of z-tweets from the anonymous author and a rating/popularity
• Payment integration to send ZCash to those virtual authors, which incentivizes quality content and posts
• additional twitter like features such as retweet/like/quote (its easier for people to adapt to new services, when they are already familiar with functionality and features)
• as you mentioned: automatic posting mechanisms to various sites: a „real“twitter account that posts new topics and headlines from z-board; but also posts to other social media platforms
• automating every aspect of the website (e.g. topic creation) using ZCash transactions, therefore keeping the z-board fully redundant
• people could post a normal z-tweet which contains a topic creation request, it would then open up a sub thread with a special z-address and viewing key (needs to be further elaborated)
• z-board API, rss feeds, etc.
• maybe private topics

Marketing:

• Referencing interesting web-articles in z-board topics
• Posting interesting content in z-board topics
• Creating special topics (books, movies, recipes, tech papers, animals, etc.) that people find useful and which encourage conversations
• sharing of tweets
• Giving conference talks and explaining the benefits (e.g. compared to twitter)
• and again the cross-linking between social media platforms (z-board could have topics which are an "immutable log“ of twitter messages, or news articles from other websites, etc.), thereby „saving fragile information from censorship-prone twitter into the immortal and secure ZCash chain“

and certainly more if I think longer about this :-)

Best,
Thomas

[zawy12]

Each message could be news or a proposed law. The community would automatically elect to finance or starve the writer or proposed law via direction of required fees from each recipient. It's required, but he would select if the fee goes to the sender of the message (or to finance the law) or to be destroyed, sent to devs, or sent back to the chain (giving the protocol permission to issue more coin in the future, enabling a cycling of coin through an internal economy)

Senders of news must also pay to send messages with similar options. They would remove recipients who elected to not direct the fee back to the sender. There would be a cap on messages per block, so only highest paying senders get to send. So there would be an evolution towards getting the "best" (most popular) news or other info.

The coin would have a reason for existing that is not threatened by any other coin. There would have to be a different coin for many different sources of information because it needs 2 tx per recipient per message. The message would be the recipient's decryption key for an RSA-encrypted article somewhere on the internet.

This could be used to select and finance a president anonymously based on the quality of his "orations". He would reveal himself at the beginning of a coup that he plans, and possibly finances via the fees received.

This is representation in exchange for taxation, automatically selecting the best representation.

The fees would need to be expressed in constant value which can be determined accurately over years by the coin's difficulty and a bounded estimator to get a Moore's law adjustment, provided the POW does not change and no algorithmic breakthroughs occur.

[tromer]

In the grant review committee's discussions, concerns have been raised about the budget of this proposal (at $80k, it would be a large fraction of the 2018Q2 grant program's total budget). Can this be addressed?

[thoschm]

Hi, when giving the numbers, we had 2 things in mind:

1. we wanted to be honest about the estimated effort
2. we were aware that 80k is a large proportion, so we split it into two chunks, which are somewhat self-contained, as we saw from past grant proposals that this is a good compromise. For the second part (42k), we could apply again in a next grant program. So, for this round we could perfectly start with the first work-package (38k). This would give us the resources to implement a large part of the proposed functionality (the full part one). And, of course it would give the ZCashFoundation a more fine-grained control over our funding.

[tromer]

The Zcash Foundation Grant Review committee has reviewed your pre-proposal, including the above discussion, to evaluate its potential and competitiveness relative to other proposals. Every pre-proposal was evaluated by at least 3 (and typically more than 4) committee members .

The committee's opinion is that your pre-proposal is a promising candidate funding in this round, and the committee therefore invites you to submit a full proposal.
Please submit a full proposal by June 15th, following the detailed structure described in the Call for Proposals. We encourage you to submit a draft as early as possible, to allow for community feedback.

[thoschm]

Thanks a lot for the positive response!

Please find our full proposal attached to this comment.
As we have perceived interest in the news-portal approach as well as the twitter-like chat platform, we have extended our proposal to cover both ideas. From an implementation perspective, the approaches can share the same technical backend, and there can be different areas (or topics) on the website (and accessible from the local toolkit): for larger news-articles and for shorter twitter-like messages. In our view this will further increase the service usability and the possible target group of users without raising implementation effort for us.

Looking forward to hearing your feedback,
Best,
Thomas

Proposal_2018Q2_AnonChatNewsPortal.pdf

[zookozcash]

Here are a few things that may be related or inspirational:

• http://z-board.net obvsly!
• https://decentwitter.com/ ← running on EOS, apparently
• http://decent.gwenbell.com/#@EwmF+Njz1JmbLDSfU+kCimaQbqca9kqtGyGXqrRgTV8=.ed25519

[thoschm]

Thanks!
We‘re planning to implement a look & feel close to twitter, while supporting also special separate topics for long articles.
Also, in the longer run, we‘re really planning to get a share of twitter users to use the platform regularly, as it will be more tailored towards crypto communities and people who like freedom of expression.
Therefore, we will also make sure to have an approach for some twitter pain points right now. (e.g. using the pubkey trust system, discouragement of spam etc.)

[zancas]

Hey @thoschm I'm looking to run some integration tests against z-board, for the purpose of validating data formats in the memo field.

I'm also tasked with organizing a Workshop:

https://z.cash.foundation/zcon/schedule/

Workshop 2.2. Is there a chance you could attend?

I'm reachable here:

https://chat.zcashcommunity.com/channel/zcash-dev

as: "zancas"

or as: zancas at protonmail.com

[thoschm]

Hi @zancas , thanks for your message, I've sent you a PM in the community chat.

[tromer]

How does your proposal compare to ZeroNet?

[thoschm]

Hi, in my opinion, the underlying mindset which led to the inception of ZeroNet is somewhat similar to the mindset we had when making this proposal, however, the approach and resulting functionality is very different.

Let me quote an official description of ZeroNet: "ZeroNet is a decentralized web-like network of peer-to-peer users. Programming for the network is based in Budapest, Hungary; is built in Python; and is fully open source.[1] Instead of having an IP address, sites are identified by a public key (specifically a bitcoin address). The private key allows the owner of a site to sign and publish change, which propagate through the network. Sites can be accessed through an ordinary web browser when using the ZeroNet application, which acts as a local webhost for such pages.[1] In addition to using bitcoin cryptography, ZeroNet uses trackers from the BitTorrent network[2][3][4] to negotiate connections between peers.[1] ZeroNet is anonymous by default, by hiding their IP address using the built in Tor-functionality. The ZeroNet website and bittorrent tracker are blocked in China.[5]"

Opposed to this, we clearly have the functionality of a news portal (with trust mechanism, virtual profiles, article rating) and a twitter-like communication platform in mind. Both of which require a certain look-and-feel and interface for sending/displaying messages and composing article/message ratings (and of course different marketing). This also includes messenger integration and specific apps/front-ends for non-technical users. Also, our target user-group is therefore different. Another goal is ease-of-use with mass adoption in mind, whereas ZeroNet is a general framework with no such specific use-case (like news portal, anonymous twitter etc.) and requires much more technical expertise from end-users.

From a technical perspective there are also major differences: For our proposal there is no BitTorrent-Tracker involved as a SPOF - we cannot be blocked by anyone (and data is only stored inside the ZCash chain). Also, we base user anonymity not only on Tor, but ZCash encryption which has of course stronger security guarantees, as the whole message-related traffic is encrypted. Tor is a nice add-on but cannot be considered a guaranteed anonymity feature (as there are of course potential statistical attacks on the Tor network). A ZCash z-transaction on the other hand is encrypted the very moment it leaves the client application, which also means that other ZCash nodes are not "serving" plain message/article data, which might expose them to risks. Also using the ZCash chain, different promises to users can be made: E.g. with z-viewing-keys it can be promised to people to restore the full chat/news history at any point in time, but they can also be used to create private/hidden communication-channels and fine-grained privileges.
Our proposal also covers shielded ZCash payment integration, whereby authors can be compensated for quality content. A platform based on ZCash therefore adds an important level of user incentivisation: writing anonymous articles and being rewarded for them anonymously using a single framework (ZCash) is a very powerful approach. Rebuilding the same functionality using ZeroNet would require several different tools and probably ZCash again down the road.
We would do it all in one go - in an elegant and much more secure way - using ZCash.

Please let me know, if I should elaborate more on this.

Best,
Thomas

[sonyamann]

We regret to inform you that your submission was not selected by the Grant Review Committee, and hence the Zcash Foundation will not be funding this proposal. Thank you very much for your thoughtful contribution!

Please consider subscribing to the Zcash Foundation newsletter so that you will be notified of future funding opportunities.

The Grant Review Committee’s comments:

Proposer is Thomas Schmiedel who would like to start a more robust version of the anonymous zboard.net. This is far more ambitious in scope and the proposers ability to deliver this kind of project is unknown. The committee members felt that this proposal was interesting but the cost was way too high for something that may not progress beyond a prototype. Funding of this proposal is not recommended.