ZPublish – Open-source Social Network With Microtransactions

Community Grants Applications
1

Proposed Solution

Initially, the platform will exist as a proof-of-concept Twitter client that allows people to scroll through Twitter users’ feeds and tip specific posts with shielded Zcash (with a memo noting the post ID). Twitter users will be able to sign in with Twitter and declare a z-address.

The next stage of the project will be to evolve the platform into an open-source social media network that can be self-hosted, allowing people to publish a microblog, articles, video, etc, and receive tips in Zcash, giving users control over their data and where it’s published. This will make social media censorship-resistant, while still holding people accountable to their hosting provider or community platform they post to. It’ll be modelled after W3C ActivityPub’s JSON API routes, and may support Mastodon OAuth2 in the future.

Users can choose where to publish their posts: they will be able to post to a Zcash memo with either a text post (to ZECPages), file pointer in the form of a link, magnet hash or IPFS (and to Twitter if API quotas allow for it).

People in the Zcash community will be able to use the platform to earn or spend Zcash, either by writing articles, publishing videos, or tipping to support content they like. This should bring new people to the Zcash ecosystem too, by having an onboarding system explaining how people can use an exchange and Zcash wallet.

Full application here:

Accompanying proof-of-concept app (standalone feature already built): Home | ZPublish - Microblog

I would love any feedback on the UI/UX, the app so far is a minimal front-end that simplifies the process of publishing a microblog post both to ZECpages and to Twitter. The idea is to expand from this to create a custom Twitter client with Zcash tweet tipping, and allowing Twitter users to export their data and self-host it on their own website later on, as part of ZPublish.

4 Likes
2

Glad to see memo based applications being explored by builders on Zcash. As for design, I am a fan of Ghost-like UX, they released a huge update after 8 years of their initial KickStarter Ghost 4.0

I’ve also seen @Ziga marketing the Zubscribe initiative which can be tied in with the micro-blog for a holistic Zcash memo based experience.

My concern(based upon the initial understanding of the micro-blogging-framework-idea): Are you going to allow each user to have their own ViewingKey based micro-blog? If yes, How would you optimize the IVK fetching for the multitude of users? Will each self-hosted setup need to run a full node? As more users sign up, the sync times to pull the data for each user would increase, or are you going to maintain a traditional database like Postgres to cache the blog for each user?

2 Likes
3

Thanks for your feedback. I’ll definitely take a look at Ghost’s UI and UX. The Ghost 4.0 dashboard UI looks really nice.

Integrating with Zubscribe could be interesting, if it’s open-source and will have some kind of API; could be a nice way to run a private messaging system.

Not initially. My main idea is to store posts traditionally in (Postgres/Redis/HTML cache), similar to noise.cash (not immutable), and offer a variety of optional publishing options, including ZECpages and Twitter, and to offer shielded address tipping, similar to Zeme.team.

The idea of integrating memos directly with ViewingKey (raw text content or pointer links) is more of a stretch goal (not sure if it would be feasible in the three months, I have very limited C++/Rust experience), and would probably require running a full node (or would light client handle the performance aspects of it?) – I should probably clarify that in the proposal. I feel that running a full node or light client should be optional for self-installs to help with adoption (shielded tipping wouldn’t need viewing key support). Also, I’m not sure on the etiquette of using an existing lightwalletd server for the project such as ZecWallet?

When it comes to front-end development, I tend to build things in a modular way, so would be keen to build re-usable UI components which could be fed back to projects like ZECpages and ZecWallet. I use https://github.com/elemental-design/elemental-react which creates a React Native compatible component library.

2 Likes
4

Isn’t this all achieved with a few UI tweaks on the existing mobile wallets - something that goes ‘ping’ when a memo arrives & an inbox to show them?

I have a mobile wallet that handles viewkeys & multiple accounts so the hard stuff has already been done.

EDIT: Here’s a link to that being done while testing a mobile wallet, creating a ‘personal ZECpages’ :-

2 Likes
5

I think using polling with zecwallet-light-cli should work, this is how ZECpages does it: zcash-memo-monitor/src at master · michaelharms6010/zcash-memo-monitor · GitHub

Could package it up into an npm module with zecwallet-cli Rust/JS bindings to automate the view key import, and have it submit the memos to an API with REST or a sockets connection. It would come down to how many ViewingKeys can be imported into a single wallet, or whether to compartmentalise wallets by user in the centrally hosted/aggregated version of the platform.

I like the idea of using memos as an NFT-style system to (as an opt-in feature) prove the authenticity of a blog post, article, photo or video.

2 Likes
6

That sounds like a good plan. Maybe consider using the lightwalletd.com infra for making calls from zecwallet-light-cli tool.

As for hosting the primary application, do you have plans to scale up if the visits/demand picks up on ZPublish?

1 Like
7

:+1: Is there API parity with the lightwalletd.com infrastructure and zecwallet-light-cli now? I understand that Zecwallet have maintained their own lightwalletd fork.

Yes, my plan is to start out with Gatsby.js (static site generator) and hosting assets with CDN infrastructure (CloudFlare CDN, CloudFlare Pages, DigitalOcean Spaces) for pre-built pages, JS bundles, images, etc (i.e. initial proof of concept web app with a pre-indexed snapshot of a Twitter profile with z-address tipping per tweet). Video support (later on) would have to remain an embed of an external service like Vimeo, CloudFlare Stream or IPFS to be cost-effective.

Then, once the code is ready, expand to hosting a GraphQL/Postgres API on a Linux box for post submission and handling dynamic content, with Redis caching of frequently accessed content – 32GB RAM, 240GB storage and an i7 should be plenty for a while I think. I may look into serverless functions like CloudFlare Workers or Kubernetes if the cost/performance ratio is worth it, but am generally keen to go the traditional route of running a full Linux server and sharding databases if/when needed. Would server location matter? I’m generally keen on EU infrastructure for GDPR compliance and protection.

1 Like
8

Yes, I believe @adityapk00 has done the work to get the lightwalletd APIs on par. We are using the same for the Zcash Block Explorer VK components.

1 Like
9

Quick update, I‘ve got a proof-of-concept up on my website of how exporting your Twitter data to your website may look like (with per-tweet microtransaction tipping): https://1337bytes.com/

The lines coming out of the profile icon indicate the post being a reply (for future conversation thread support). The data is hardcoded JSON from a Twitter API response for now, but once the caching (Postgres/Redis) back-end is implemented, we can pull in live data from Twitter, ZECpages, on-chain ViewingKeys, etc.

10

I think this kind of apps should be built on another platform (Horizen?) because the zcash blockchain will fill up quickly. I would hate to have to download Gb of user posts that I don’t care about.

2 Likes
11

I disagree, layer 2 specific blockchain (not referring to Lightning Network, but that has it’s own problems) adoption is generally quite weak when it comes to exchange support, and will not be very good for usability in Europe, Africa, etc, and liquidity will be a big problem.

In any case, as I mentioned above, my idea initially was not to broadcast each microblog post as a transaction, but to store it traditionally, and to support a ZECpages integration for those that wish to have that as a feature. Then depending on community feedback, I could integrate memo support directly, as an opt-in feature. When it comes to microtransactions, surely we should be encouraging tipping based apps, even if people are tipping small amounts? I know Lightning Network is designed for microtransactions, but it’s not exactly the best for privacy or custodianship…

I‘d say it mostly comes down to the layer 1 vs layer 2 scaling debate. Bitcoin Cash, with projects like read.cash, has a blockchain size that is only 170GB – running a full node can still be done with relative ease. Zcash has the unique advantage that with projects like Halo, on-chain scaling could be possible via sharding, etc. Ethereum has a tonne of transactions going through it with crypto kitties, etc, but the blockchain size is only 260GB, still totally manageable with a 512/1024GB NVMe SSD.

1 Like
12

I suppose we are not talking about phase 1 since putting each post in a db does not involve zcash very much.
In phase 2, posts will go in the memo field inside transactions. We can talk about scaling plans in the future but the reality is that right now, these will take space in the blockchain.
The zcash transactions are bigger than bitcoin and ethereum’s. The simplest zcash shielded tx takes 2+ kb because of the memo and zksnark proofs. In comparison, bitcoin and eth tx are ~200 bytes (depending on the # of inputs, outputs and params).
I think there is a scalability issue, either the project won’t see much traffic or it will fill up blocks.

Since this data is not particularly interesting to me, I’d rather not have to download and keep it. No one can stop you from doing it but I think it puts pressure on the block size.

13

Messaging based on zk-channels ‘layer 2’ would be much more interesting.

14

Phase 2 refers to an integration with ZECpages, which already exists and is being used as an immutable and anonymous message board; encouraging/enabling more use of it could bring many new people to the Zcash ecosystem.

I feel that one of the most exciting applications of memos is immutable text posts, IPFS pointer links, magnet links, etc, especially in a social network context. Memo pointers to IPFS files is one of the main ways in which love notes work, which is an integral part of Zcash.

I do agree that there needs to be a discussion around “noisy” transactions, but it’s worth keeping in mind that apps like ZECpages already exist, there‘s Zemo, etc, so feel this discussion would be better in a separate thread. I don’t think anyone wants to go the BSV route of 2GB blocks :slight_smile:.

In any case, the main idea of this project is the microtransaction tipping aspect to support journalists, content creators, writers, filmmakers, etc, and the Mastodon style network to support it (i.e. read.cash and noise.cash, but decentralised); direct memo integration would definitely need user testing, community feedback and benchmarking/metrics (on testnet), and isn‘t really in the scope of this application: it‘s more something that either I, or the community could implement in the future with plugins if there is a lot of community interest.

15

zkChannels are definitely interesting, and I hope that once stable, they help remove some of the drawbacks of the Lightning Network and can be used in the future for microtransactions, especially tipping under 0.0001 ZEC. I don’t think it would be fit for immutable data, but if they have ViewingKey support, would be nice as a sort of pubsub system to leave a message/note/action with a tip (i.e. unlock an article or content with a transaction).

16

Not even sure messages need to be immutable, I’d settle for secure & distributed delivery - zk-channels should do that quite nicely

17

I was referring to the idea of immutable posts/articles/videos, not messages. Once/if zkChannels are stable, they would definitely be useful for point of sale or microtransactions, but for distributed/secure messaging, Signal protocol or Matrix would be more appropriate (currently) imo.

Re messaging for this project, that would be through Postgres/Redis/ActivityPub initially, and I‘d be keen on integrating a community-made messaging solution for messaging on-chain or via zkChannels once those exist, pending community feedback.

18

Regarding your grant, it seems to me that it’s N% social network and (100-N)% zcash (tipping).

The social network part can be obviously very complex, i.e. Facebook. I’d like to know what you think N should be.

Initially, the platform will exist as a proof-of-concept Twitter client that allows people to scroll through Twitter users’ feeds and tip specific posts with shielded Zcash (with a memo noting the post ID). Twitter users will be able to sign in with Twitter and declare a z-address.

That’s pretty cool and I like it.

The next stage of the project will be to evolve the platform into an open-source social media network that can be self-hosted, allowing people to publish a microblog, articles, video, etc, and receive tips in Zcash, giving users control over their data and where it’s published. This will make social media censorship-resistant, while still holding people accountable to their hosting provider or community platform they post to.

I don’t fully understand this part. You say people can self host and it’s censorship resistant. Do you mean in the sense that one can host anything he likes?
But not in the sense that it can’t be taken down? (Your ISP can shut you down).
Are we talking about something like Jekyll?, Ghost? NodeBB? This forum?

Users can choose where to publish their posts: they will be able to post to a Zcash memo with either a text post (to ZECPages), file pointer in the form of a link, magnet hash or IPFS (and to Twitter if API quotas allow for it).

Personally, I’m ok as long as it is not zcash memo.

Thanks for taking the time to submit this proposal.

2 Likes
19

I love it and i think you should keep putting something, anything, in the blockchain until it fills up. We can scale when we have to, its the squeaky wheel that gets the grease, rather than the geeky wheel that gets the screech, or something

4 Likes
20

It’s hard to quantify, but initially I’d say 20% Zcash tipping, 80% social network; the social network part being necessary for the microtransaction tipping.

The main value of the project would be to attract new people to the Zcash ecosystem: i.e. “Oh, I can download my Twitter account onto ZPublish and host it on my own server? Cool. Oh, what’s Zcash, I can earn money from my tweets?”

Thanks; the idea is inspired by Brave/BAT tipping and medium-to-own-blog, but instead of having a Chrome extension (which could kill adoption), you can create a clone of your Twitter profile, or have the app be a custom Twitter client (subject to unsustainable API quotas) that you can sign into via Twitter OAuth2.

Yes, it would be runnable as a server on your own box, optionally with a light/full Zcash node. Deploy to a home server, Linux box, Docker, AWS/GCP/DigitalOcean, etc.

Essentially, it would be a more versatile version of Mastodon, but with a headless and modular UI framework that can expand to video posts, photo galleries, etc, all with Zcash tipping as a core feature. This is something that could be built on top of the Mastodon API, but I’m a “build everything myself” guy, so am more keen on implementing the ActivityPub specification, making it easier to port in GraphQL/Relay support (React.js data fetching/caching library), crypto wallet addresses, etc.

There would be an “official” centralised instance to help with adoption.

I didn’t really mention in the proposal, but the plan is to release a bunch of open-source component libraries, implementations, etc that people could use for other apps, i.e. hosted wallet solution for content creators (weighing up usability vs security risks) – which could later become a BTCPay Server alternative. I’m not sure how much of that could get done in 3 months though. That’s my main problem with projects like NodeBB, Ghost, Discourse; they don’t have modular/encapsulated UI components. Sure they have theming engines/plugins, but PHP has been left by many for a reason…