>New feature where you can now encrypt a Thread on BlockChan and only those supplied with the Key and Initialization Vector (IV) may view or post it. This is designed for if you want to have a discussion in public that can't be taken down or tampered with, but you only want those with the key to be able to view or post.
>Mobile U Enhanced/Cleaned up The mobile sight was awful and not very usable. This has been remedied.
>Coming soon: Ability to create your own board
>Why BlockChan? -Hosted on Ripple and can't be taken down -Post are immutable and can never be deleted or tampered with -No Mods/No Jannies -Just needs an internet connection and works even if DNS is down. -The only way to stop it is to take down Ripple which is a 15 Billion dollar company -You don't have to be a node operator like on Zero net -While payment validations are technically centralized, the ledger is decentralized and thus, for all intents and purposes, BlockChan is decentralized -Ability to Encrypt Post
>Hosted on Ripple and can't be taken down are you sure about this statement? Regardless of your good work, The Ripple Network is big pile of centralized shit and could censor anything like WAVES did in the past.
Connor Moore
>good dev, sorry noone cares enough ;( Yeah, I honestly thought this would get more traction :(
>are you sure about this statement? Regardless of your good work, The Ripple Network is big pile of centralized shit and could censor anything like WAVES did in the past. The way it is implemented, it would cause major negative ramifications for ripple in that they would have to remove payment and account histories from ripple transactions that smart contracts are based on.
Jackson Hall
>posting potential racist hatespeech on a blockchain so it will be stored there forever, instead of an imageboard where it at least gets "deleted" after some time. >literally after 8ch died.
Is this a glownigger operation? Asking for a friend.
Parker Adams
>good dev, sorry noone cares enough ;( Yeah, I honestly thought this would get more traction :(
No worries just post on Jow Forums and ask them to post on your board when the next shooting is announced. :>
Asher Cooper
>Is this a glownigger operation? Asking for a friend. No. It's completely open source. And the client is downloaded directly from github from the source repo. I encourage it to be combed through
>No worries just post on Jow Forums and ask them to post on your board when the next shooting is announced. Sigh, that's grim bad sadly accurate in today's world
Ayden Rogers
Of course its open source. But thats not the problem. The problem is that threads are stored on an public blockchain.
I saw an encrypted thread. How exactly is that working?
If there was something like zk encryption it would be actually cool. Telegram is tyring to do something similar with moving to an serverless messenger that is secured by blockchain.
>Sigh, that's grim bad sadly accurate in today's world
Are you ready to get /van/ned for creating this project? Do you have an exit strategy if shit hits the fan? Lets hope your baby is ready enough before the first shooters announce there.
Brayden Hughes
Ok I tried encrypting. This is actually pretty impressive.
How exactly are those threads stored on ripple?
1. Can someone from outside know the filesize of those threads. 2. Can someone from outside confirm who is creating those threads? 3. Is it possible to change encryption, one a private key is "leaked"? Maybe by a thread creator? 4. Are the admins able to delete threads, get WHOIS information ot the poster, or break the encryption?
Will there be an option that enables threads with an expiration date?
Zachary Rivera
>I saw an encrypted thread. How exactly is that working? An AES 256 key and Initialization Vector is created in memory in your browser and displayed on the screen when you click generate key. The Post is then encrypted with that Key and IV and the encrypted data is stored on ripple blockchain. When someone pulls the thread up, it pulls the encrypted data from ripple and then if they know they key, it is entered and applied and decrypts the post
>Are you ready to get /van/ned for creating this project? Do you have an exit strategy if shit hits the fan? Lets hope your baby is ready enough before the first shooters announce there. BlockChan doesn't host anything, the data is hosted on ripple and the images is hosted on IPFS with the pointer hash stored on ripple. All BlockChan really is, is a client that sends payments on the ripple blockchain that obtain meta data readable through the IndImm Messaging Protocol. This would be like V&'ing or sueing the creators of tcp/ip, the creators of modems or the creators of Ethernet cables
Cameron Hernandez
>How exactly are those threads stored on ripple? The data is stored as JSON object converted to a Base64 String. This really just a fucking Jason Parser. The images are stored on IPFS with the hash pointer of the image stored on ripple
>1. Can someone from outside know the filesize of those threads. It would be possible for them to create a tool to do so. BlockChan is really just a client that is using the IndImm protocol >2. Can someone from outside confirm who is creating those threads? Only if the ripple ledger logs the ip of people who makes payments and only if IPFS logs the uploader of an image. If you want to be secure, you'd need to use a vpn+tor >3. Is it possible to change encryption, one a private key is "leaked"? Maybe by a thread creator? No. Anything posted is Immutable by design >4. Are the admins able to delete threads, get WHOIS information ot the poster, or break the encryption? There are no admins, just me, the creator. I could modify the BlockChan UI to not show a post, but it is impossible to delete. Again, BlockChan is really just a payment interface using the IndImm defined messaging protocol (I have not officially released the protocol). Encryption can not be broken by admin. The Key and IV is only on the creators browser memory, their UI of BlockChan and whoever they share with
Dylan Brown
>It would be possible for them to create a tool to do so. BlockChan is really just a client that is using the IndImm protocol
How hard would it be to let the threads only contain the hashes that link to the files, that even without the encrypting key users would not know the size of the thread? Would be also cool if people without encrypting key would not know about the number of replies, date etc. The less information the better.
It also would be interesting to know how ofter the decryption was used. So that people know that their key was maybe leaked.
Another thing. Read-only threads could be interesting as well.
Cooper Cook
>How hard would it be to let the threads only contain the hashes that link to the files, that even without the encrypting key users would not know the size of the thread? Would be also cool if people without encrypting key would not know about the number of replies, date etc. The less information the better. That would all be something possible and something im considerring
>It also would be interesting to know how ofter the decryption was used. So that people know that their key was maybe leaked. That is definitely possible and I will note it as a future possible enhancemnt
>Another thing. Read-only threads could be interesting as well. I will definitely implement this in the next week. That is a brilliant idea. Though how would it get bumped or would that matter?
William Butler
exiting stuff dude. Thanks and keep up the good work.
>Though how would it get bumped or would that matter?
Those threads could be only bumped by the creator of the thread. It would likely use the encryption too, but instead of not showing the content for others....it would show contents to everyone. This would be awesome for whistleblowers to confirm they are the same person providing leaked information. since only the person with the key can post in those threads .
Since its possible to link via >> to threads I guess people will start their own discussion threads related to such read-only threads if there is some serious shit being leaked in there.
Lucas Gonzalez
I do like this idea a lot, however how would I prevent someone from creating a read only thread and just bumping it ad nauseum? I suppose I could charge like 1 XRP per bump
William Clark
How do you prevent someone from pumping a normal thread ad nauseum?
David Diaz
Good point, that reminds me, I need to add the ability for a user to hide a thread and not have it show up for them again
Adam Ortiz
Also think about read-only thread like huge information threads from people collecting usefull information. Like on of those megathreads you see around here.
example: Eppstein thread. Which is only used by one guy colelcting data.
Wikipedia articles so they cannot be deleted or altered.
Historical events that cannot be altered.
For stuff like this a read-only mode would be very usefull and cool. We could finally start to write history without letting (((them))) change it afterwards.
Grayson Parker
I am definitely sold on this idea and will begin implementation
Jordan Johnson
Another question:
>-While payment validations are technically centralized, the ledger is decentralized and thus, for all intents and purposes, BlockChan is decentralized
Does that mean, BlockChan can operate automatically if people donate ripple to the public adresse?
Juan Williams
automatically and autonomously I mean. So even if you are gone, v&ed for example. Also do you hold private keys to those public ledgers?
Christian Wood
It will operate as long as the public address has greater than 20XRP.
Yes, I have the private key for each address that the posts are "sent" to, however I have a prototype that uses random address to even more so increase the immutability and the ability to not allow ripple to censor if they ever tried to
Ayden Fisher
Thanks for your honesty. But I think it is a bit of an downside that you hold the private keys to the ledger. I mean I get that you put the time into this. But this also means that donators would need to trust you because you could move the funds out if I understood correctly.
The optimal solution would be an adresse that automatically pays for the posts, maybe via smart contract, that noone has the private keys (If this is even possible) That automatically pays for the messages posted on the imageboard. This way it could completely run autonomously.
Hudson Taylor
Also another question:
Currently the speed of the site is a bit slower then common web2.0 imageboards. Is this related to ripple? How is scaling fixed long term on ripple? Or is the speed issue more on your side.
Ryder Wright
I'm actually working on that and will be using LINK for that an additional functionality if this ever kicks off
>Currently the speed of the site is a bit slower then common web2.0 imageboards. Is this related to ripple? How is scaling fixed long term on ripple? Or is the speed issue more on your side. That is the main draw back is that posting a post has to be validated on the ripple ledger, so round trip time from sending and validating is 6-8seconds.
Loading the page uses ripple websockets and the connection has to be initialized first which takes a second. There are performance increases that I am working on, but they will take time. With that said, It will never be a less than 1 second page load. I don't think that is too paramount though, but it seems to annoying people. I guess being used to 100ms page loads will do that to people
Isaac Brown
>I'm actually working on that and will be using LINK for that an additional functionality if this ever kicks off
o-okay. Nice meme there! Please also use atomic swaps so that I can pay with dogecoin please.
>Loading the page uses ripple websockets and the connection has to be initialized first which takes a second. There are performance increases that I am working on, but they will take time. With that said, It will never be a less than 1 second page load. I don't think that is too paramount though, but it seems to annoying people. I guess being used to 100ms page loads will do that to people
yeah that might be a problem. But if i understand blockchain tech correctly, it should not really be possible to:
1.) DDoS Blockchan 2.) The 6-8 post time will be always roughly the same even if the sites hits the traffic of Jow Forums.
Also a little tip: Post this thread not only on Jow Forums also post on other imageboards, 7chan, 420chan, kohlchan etc just to name a few.
Also what do you do to prevent spam? If i understand correctly. If (((they))) would decide to create massive amounts of posts the ledger could be sucked clear after couple of tenthousand of posts. There will definetily people starting to use bots to spam that board in the future.
