1. TON Web
Link (more detailed info): https://tonweb.site

A smart-contract, which helps to store files directly in its persistent storage with support of get-methods, used in tonweb.site.
Smart-contract itself is written in Fift/FunC.

todo:
- scripts to send messages with editing/deleting/creating new files in smart-contract (contract has this functionality, but it wasn't tested properly and is not used now)

2. TON Mixer
Application link: https://tonweb.site/-1:2bcc9840e7b9ec6b77fe3543b4eefbf3ba6c69fd98f362b3d3b2f4b752adb5e8

A service, which helps to anonimize the source of Grams.
Smart-contract address is just one of current working nodes.

A service uses default wallet codes (fift, func) and is written in Node.JS using toncenter.com (thanks @rulon for such great work)

In screenshot you can see, how it is working on server side. Now another nodes are active.

Continuation of an answer to Chic Dolphin:

3) "Because the way you select nodes is deterministic (ordering by balance) upon seeing incoming transaction I can predict which nodes will handle it."
Yep, if you know balance of each. Is "predictable" bad in this case?
But, as I said, maybe I should have submitted version, where more than one node send transaction back.

4) "Another interesting choice is that if you don't have enough money (how is that?) you simply don't send full amount."
I warn user, before his transaction, how much money can I send him back.

About that mixer. If I read the code correctly there are nodes, if I want to hide my transaction I "reserve" some random node. I send my grams to that node, and once it detects balance change it orders other nodes to send me that balance within 30m interval.

So the obvious problem is that there is only one output. If I send 100 grams, it isn't difficult to find a wallet that received 95 grams 30m later.

Alternatively I can discover all nodes either by submitting api requests, or watching those that leave 0.15 gram balance (MixerNode.minStake). Because the way you select nodes is deterministic (ordering by balance) upon seeing incoming transaction I can predict which nodes will handle it. In worst case scenario first that will have enough balance will handle it all.

Another interesting choice is that if you don't have enough money (how is that?) you simply don't send full amount.

I believe there's no way of making good mixer until zk-SNARKs are implemented. I would focus on this.

> In empty network, it is obvious to find hidden transaction, as it would be only one in the system.

Let's say we both wanna hide 100 grams, we secretly communicate with each other exchange our destination addresses and toss the coin. If it's heads then we send 10 grams to each other, if it's tails then we send 10 grams to our own destinations. And we repeat that process 10 times. The net result is that no-one else except us two knows whos destination belongs to whom.

It's not about transaction count. It's about ensuring that transactions are indistinguishable from each other. Scale that to more users, make sure they burn the records afterwards and that's mixer.

Storing big files entirely in blockchain is very expensive, so the implemented approach is hardly to be widely used. It also seems that big files can't be uploaded at all in this way.

The mixer seems to be too simple to provide real anonymity.