Looks neat, I'm a little starved for Go examples in the documentation--I found a couple undocumented example programs in the repo, but I'm not spotting anything in the docs that shows how to do the basics. In fact it took me a bit to even realize there are Go libs, I had originally posted a comment asking for something like ThreadsDB in Go before I spotted the link in the hamburger menu!
Thanks! I've been looking for a distributed key-value store where any node can update or delete any object in the store, and which can handle partitioning in some fashion... I'm hoping ThreadsDB might be it! Perusing the docs to see if that's true :)
That's awesome, dig right in! And don't hesitate to reach out on our slack: slack.textile.io. We're under active development, so if there's something missing, or a feature that's lacking in documentation (there are, but we're working on it!) let us know.
I think Textile and its underlying protocols are a step forward that's actually shipping. But it looks a little like an IPFS take on Firestore, but correct me if I'm wrong. But maybe that's because I've been working on too much theory with a distributed protocol of my own for too long rather than getting my hands dirty, ha. Perfect is the enemy of good.
That wouldn't be bad if done right! I think there are still "Firebase of IPFS" products yet to come. What we do that is a bit different is that we allow devs to claim some hosted resources (IPFS, Threads, etc) and then grant access to those resources to their users. But what is different than most web2 is that the end-users can still own and keep their data (through encryption, pk identity, content addressed data).
Messing around with some other IPFS-based tooling previously (I think 3Box), I found that the user had to install and be running IPFS in order to view a truly decentralised client application (or there had to be an intermediate webhost that did this for you). This, for me, removed some of the benefits of the decentralised model.
Is the Textile toolkit able to operate directly 'on chain' via a standard web browser? Or do visitors still need to install and run executables locally in order for it to work?
Sorry if I've inaccurately slandered 3Box here - I am still learning about this space, and I am very excited by the possibilities!
It's funny. Web2 got so many things right, but early Web3 often tried so hard to abandon it all that it made for a lot of unnecessary pains. We've tried to take a more balanced approach. Decentralized where it makes sense (user data ownership, interoperable data models, data storage) and hosted/curated nodes where it makes sense (app resources, trustless services/gateways, relay services). We think we've come up with something compelling and pretty simple.
- We love the 3box team and product and its probably come a long way since if you haven't poked around recently. We are also working with them to make sure our things are interoperable with theirs. So look out for more updates in this area soon.
There is no chain. It uses a set of protocols that have no consensus. They run in the browser. Here is a relevant merged feature in the ThreadsDB library today, https://github.com/textileio/js-threads/pull/136
That is a problem indeed. Everyone expects to not have to install anything and just freeload off of someone else's gateway and still have all the benefits.
If you don't install the client, it's not a decentralized system, you might as well run WordPress and call it a day.
I haven't seen anything big in WASM on Textile yet. It should be done for sure. We use Slack because it was there and worked when we needed something. Onboarding is easy, our chats are open to the public already, and we didn't need anything fancier than there free plan.
We've been considering a move to Keybase but haven't made the move yet. Matrix is also the jam so we can just be everywhere at once... but we don't have the demand yet.
