mbalex99

I wouldn’t say I’ve had horror stories just minor gripes and frustrations. You can mix and match AppKit and UIKit with SwiftUI. So there is always an escape hatch.

SwiftUI is insanely productive when it comes to building mostly simple list and form applications.

I highly recommend that you try it, you can always build a component or large sections using UIKit if you run into issues.

At Ditto almost all of our enterprise customers use SwiftUI over UIKit because SwiftUI is so productive for the vast majority of use cases. Does it have parity with UIKit? No… but it’s never been a dealbreaker for us.

Ditto (www.ditto.live) is deployed on all Alaska Airlines, Lufthansa and many other airlines.

It also powers point of sale and kitchen systems at Chick fil A.

The major thing that Ditto is that it can sync without internet using Bluetooth low energy, peer to peer WiFi and Local Area network. It can even do multi-hop.

Do you mean actual databases like MySQL, Postgres, SQLite, MongoDB?

Or more user oriented databases like HubSpot, Salesforce CRM, Microsoft Access?

Faster is a key value store where the value can be a CRDT thanks to its Read Modify Write capabilities.

A 3D Modeler attempts to recreate a real camera virtually by simulating light and physics

Thank you! After feedback from a lot of our customers, they want more access to explicit types so you'll see a lot more APIs to control how you want conflict resolution.

I would say:

A) PouchDB, Couchbase, Firebase, Realm are all databases that can sync to a "master" node in the cloud.

B) AODV and BATMAN are really an ad-hoc mesh networking and routing protocol.

Ditto is both A and B. You work with Ditto as a database on your mobile, IoT, web app with common database functions (querying, updating, deleting etc...) and we will sync the changes between edge and cloud devices. Most developers cannot sensibly use AODV and BATMAN to build robust collaborative applications, it's too hard. We abstract all of the routing, network resiliency, and replication away from you; just work with the database

We have a mesh network that syncs devices using P2P wifi, BLE and over a LAN as well!

I think this is our biggest differentiator compared to other sync systems.

No unfortunately not in our core offering. We’d like to stick to what we do best and then leave it up to the community next year to build a graphql implementation.

We will be working on granular permissions as a top priority in 2023. We have a couple of ideas running around right now.

It’s just my cofounder Adam and I that came from Realm!

We’ve got Alumni from Pusher, Basho/Riak, Walmart Labs, Microsoft, to name a few

Thanks!! We will make improvements.

Our replication system is very complex. I am not sure that even publishing our spec would get much usage because it’s so complex.

But maybe we can open source an API?

Thank you so much!

We use multihop ad hoc network connections! That’s the BIG thing that we add to the mix!

You hit the nail on the head. We are working on this as a major initiative to solve the problem you detailed. As you can guess the truly decentralized authentication is quite new and we are releasing some features to get us less reliant on online services for connectivity.

That’s correct the browser limits us to do automatic discovery sadly.

WebBLE support is on our roadmap though!

However, if you use Ditto in an electron (and soon Tauri) you’ll be able to take advantage of multicast, BLE, P2P WiFi etc… while “feeling browser”-like with your development.

Stay tuned :-)

We are working on this! Give us a bit!

Max, CoFounder of Ditto here

So happy to see the support from the Hacker News community.

I should mention Ditto is a massively ambitious company, we are doing fantastic with traction across major industries.

Our entire core code base is written in Rust and I know HN goes crazy for Rust. If you’re really interested in working on very hard problems like CRDTs, partial replication, query based replication, peer to peer adhoc sync, mesh network or distributed security: please definitely take a look at our openings.

www.ditto.live/jobs

You’ll work on problems that are incredibly difficult, unique and rewarding that you won’t find anywhere else!

Max, CoFounder of Ditto here.

Super cool to see us on HN! The use cases are for projects, products, enterprises to build collaborative apps that can sync with the internet but fall back to local P2P connections when internet connectivity fails. Furthermore we added offline first as an additional guard for some resiliency.

We help solve a class of apps like:

1. Desk-less worker apps for the enterprise: think people who use mobile apps for the vast majority of their work: pilots, flight attendants, construction, maintenance 2. Retail, inventory warehousing, point of sale systems where being able to communicate between kiosks, service tablets, and display systems quickly even if there are interruptions in service 3. Education: it’s very often parents give their kids phones without a data plan, so their school or learning apps need to be able to collaborate with other students or teachers regardless of connectivity 4. Robotics, agriculture technology, IoT - often these applications have hard requirements to communicate with other local devices without any dependency of the internet

I can keep going!

Again, So happy to see us on HN! Thank you!

Thanks so much for the kind words. We have a huge set of write ups and presentations on our delta state CRDTs coming soon! Stay tuned!

Ah sorry! :-)

You see how hard it is to change perceptions? This is why people spend so much time on branding for developer tools, databases, and infrastructure companies.

Sure! In our documentation we go over some of the details here: https://docs.ditto.live/javascript/common/how-it-works/crdt

I'm not sure if you know what CRDTs are but they're a family of data types that allow different actors in a distributed system to edit data concurrently even during network partitions. If enough data is shared, they will deterministically agree on the same value. They kind of give that "google docs" behavior if you're looking for an analogy. They're perfect for peer to peer and offline-first systems.

However there is actually more to it, and a much more detailed write up is coming soon. Ditto is a distributed database, each peer has it's own database. The database is organized into collections and each collection is a Ditto Document (this does not work like most NoSQL document databases). Each property of the document is it's own CRDT, you as the user can pick which CRDT you'd like to use, our current catalog includes:

* Registers (Causal Last Write Wins) * Counters (sums of each writer's numeric values) * Binary Attachments (same as a Register but you can put large arbitrary data like say video files, images, PDFs whatever) * AddWinsMaps (coming soon) - This type allows for concurrent upserting and removing of values based on a key. * ReplicatedGrowableArray - this is an array type that allows for concurrent insertions while preserving some semblance of order. It behaves rather closely to a collaborative text editor merge behavior.

Our AddWinsMap and ReplicatedGrowableArray are more special than you might think. They can actually host nested CRDTs. Think of it like a folder within a folder in Google Drive that can hold synced documents nested within.

I'd love to show you over perhaps a call! We tend to be perfectionist when it comes to documentation and have been so busy that we haven't fleshed it all out. Perhaps we might just open source our CRDT system.

Email is in my profile, I love chatting and sharing about this stuff!

Regarding similar services? Kind of!

Ditto is both an embedded + cloud database + a mesh network, it's really 2 startups in 1.

A) If you're looking for just offline-first and data sync, there are some company's that have done this

1. Realm (MongoDB) - this is the company that my CoFounder and I came from. 2. Firebase (Google) - one of the biggest inspirations for me personally in data sync. 3. Supabase - a very popular growing open source Firebase alternative 4. All the GraphQL Backend-as-a-Service like Prisma, Hasura etc... These have offline caching with a lot of the GraphQL client libraries. I don't think actually have a database underneath the hood that you can query.

B) If you're looking for just mesh networks:

1. Build it yourself using Bluetooth Low Energy, Local Area Network, P2P Wi-Fi Direct, Apple Wireless Direct, Wi-Fi Aware APIs that come with most of your device frameworks. Build an advertising system, a common communication protocol, and add your identity security system. If you want multi-hop, you'll need to create a dynamic routing and presence system on top of it. After that design an API to send data around, respond to errors. If you want offline-first you should research CRDTs and try to build a database replication system using the mesh network. 2. You could use Apple's Multipeer Connectivity framework: this is iOS, MacOS devices only. No multi-hop here but you can build a system on top if it. One thing I've noticed is Apple's framework is a ruthless battery drainer. My phone gets very hot after a minute. It doesn't look like it uses Bluetooth Low Energy and it's advertising system seems to be extremely aggressive 3. Google has an abstraction called Nearby Messages that uses Bluetooth Low Energy. It isn't very stable but you could try to trick it to re-establish connections. After that you'll want to investigate how to pull off multi-hop. It's the same as step 1 and 2 https://developers.google.com/nearby/messages/overview 4. There was a company called Hypelabs that offered mesh network solution, but not the offline-first part. I'm not sure what's up with them 5. There's another company called Bridgefy https://bridgefy.me/ that built a chat app used in some of the Hong Kong protests 6. Open Garden also had Firechat in 2014

Ditto is a combination of both families of problems, it's basically creating 2 startups at the same time (mesh + distributed database):

* Offline first embedded mobile, web, IoT database called the small peer * A large distributed database in the cloud called the Big Peer (this is new and what we need to operationalize for general avaiability pricing) * A replication engine that uses our mesh network powered by Bluetooth Low Energy, Local Area Network, P2P Wi-Fi Direct, Apple Wireless Direct, Wi-Fi Aware

The problems that we have to tackle are so crazy; network optimizations, compression, multi-plexing, conflict resolution, scaling on the edge and cloud etc.... It's like the product that we're trying to create is teaching us as we build. For example one of the challenges that we have now with multi-hop is scaling performance. A large mesh of 1,000 devices may chatter so much just on the distributed routing table that it can cripple the replication of the actual data! So we are trying novel ways to dynamic route data by also incorporating special characteristics of CRDTs so that chatter is reduced and performance increases. Other major things we will improve are ways to prevent denial-of-service attacks even with trusted actors, decentralized access control of data, graph centrality theory etc...

Regarding use cases?

1. Well anything that's latency sensitive is perfect for us. Think controlling robots, syncing whiteboard pen strokes across devices, games, VR+AR. 2. Industry wise, any place where _any_ issue to internet connectivity means a loss of money, life, user experience: aviation, hospitals, point of sale, education, manufacturing, defense. A lot of our customers have internet 99.9% of the time but even that 0.1% is a nightmare that causes great issues.

Regarding pricing, we are actively working on a general available pricing for our entire system. This is going to take us a couple of quarters to operationalize everything; we have a pretty good idea of what the pricing will be for the everyone-version.

Right now we have our enterprise pricing nicely figured out. This might sound a bit strange but unlike many startups, we actually went to market backwards by focusing on the enterprise first. When we started the company, we had this crazy idea that we could build a distributed, query replicated, database that could sync over a mesh network. No one had ever built anything like this and we had some skepticism that such a product could actually generate revenue to create a sustainable business. Eventually, most infrastructure or database startups survive in large part to enterprise deployments. So we sought enterprise use cases and dollars first. And I have to say that was totally worth it and we've been rapidly gaining customers here.

However, in our hearts, we are all frontend web, mobile, IoT app developers that all wanted to build collaborative apps like iMessage, Figma, Miro, Trello that had offline, sync, and conflict resolution capabilities out of the box. Once we make a couple of product and ops advancements over the next could of quarters, we will have very clear pricing like any other service out there. So just hang tight!

Want us to get to pricing faster? Definitely recommend some of your infrastructure, kubernetes, and rust distributed systems developers to join us. We are hiring hardcore!

My startup built an SDK framework that’s allows companies to build offline apps that can even sync over a multihop mesh network. It’s powered by a CRDT to handle the conflict resolution.

From my experience most of our customers are not mobile developers (they’re JavaScript developers asked by their bosses to build mobile apps) and don’t even want to spend time learning coredata or room for iOS or Android. So most of the time they just stick to what they know, HTTP requests.

Luckily we made our SDK easy to use so that these JavaScript developers can get both the network communication and the offline first caching in one product. They absolutely love it.

Most apps aren’t offline first because it’s so hard to build the infrastructure to pull it off without a lot of bugs. Most apps focus entirely on the UI code layer. If infrastructure and frameworks made this a lot easier to use, I bet offline first would be a lot more popular and users would be a lot happier.