Edit: the parent comment now seems to better reflect the below.
That article is only saying when you opt out there may be a loophole in the terms to allow OpenAI to train on the intermittent reasoning data anyways. If you don't opt out there is no ambiguity, all of the data can clearly be trained on.
So you have to opt out, it's just argued it's not clear from the terms that will also opt out of training on reasoning data or not.
Depends on how much risk they are willing to accept. What is strange here is that it's clear that OpenAI is both a service provider and a competitor to mathematicians. It almost reminds me of Amazon which both hosts external merchants and competes with them, sometimes copying their stuff. Similar but not the same.
This would be a fairly insane breach of trust and common sense if true; the chain-of-thought / reasoning trace is, from an information perspective, close to a superset of the prompt and model response.
how is this different than translating user prompts to a different language (eg English => Dutch), retaining the translation and using it for training, while telling the user that he's technically covered under ZRP? article locked for me
I think the EU mandate forces them to do both, so that devices with AWDL are not advantaged over non-Apple devices with Wi-Fi Aware, so my read is that mandate will mean Apple devices will do both modes until they can transition AWDL off entirely.
How would an open implementation be compatible with this, given that Apple's implementation is based on an Apple-operated PKI?
Note that this is only a conversation about sender identification, which allows sending to a "non-world-visible" receiving device and confirmation-less sending to devices with the same iCloud account on them. Anonymous sending isn't cryptographically gated by Apple, to my knowledge.
That still requires you to have (access to) a Mac and an iCloud account.
It might be possible to reimplement the required Apple API, but as demonstrated by the iMessage/Beeper saga, they usually shut such things down pretty quickly.
Adam (CEO of Ditto) here, Mongo is transitioning to a partner-first strategy for mobile and edge applications. We are working closely with Mongo to create a cohesive product experience between Ditto and Mongo Atlas. High-level that is a supported bidirectional connector between Atlas and Ditto's Edge Sync platform.
Furthermore, we are working with customers of Atlas Device Sync to help and support them in the transition. There are aspects of Ditto different than Realm - most prominent is that we are schema-less. This will mean some client-side code transition, but longer-term a tighter alignment with Mongo Atlas. We are excited as well to introduce more to Ditto's unique capability of P2P device sync.
Note, I previously worked at Realm before the Mongo acquisition and even before joining the team I was an avid fan of the database. I hope it continues life via the community!
It is great to know that there's a logical successor.
As I mentioned above, I work in a company that offers a SAAS that's based on the Device Sync solution. We were weeks away from announcing a collaboration-oriented product based on Atlas, but now these plans are in shambles.
We are actively looking into Ditto now, and the P2P approach to sync is genuinely impressive. So, a couple of questions for you:
1. Is there something in your platform resembling the Flexible sync functionality of Atlas?
2. Do you feel that the partner-first approach will open up some space for Ditto? Have you encountered any Atlas Device Sync functionality that would be impossible to replicate for Ditto in terms of integration with MongoDB?
1. Yes Ditto uses query-based sync. Candidly, the flexible sync in Atlas has roots back to when I was VP of Product at Realm. It was a must for me, but I think got abandoned for performance issues then brought back. Ditto was built always to support flexible/query sync. We recently have added our own more advanced query engine - DQL (SQLish) and it will enable JOINs and other advanced queries while still being schemaless JSON collections. In this regard Ditto is a better compliment to Mongo than Realm is from data model perspective.
2. Yes this partner-first approach is huge opportunity for us. Given Realm had to sell, we were very focused on building a sustainable business. This meant though more focus on enterprise and specific use-cases than going wide to all developers (you can see how well that worked with Firebase, Parse, and many other developer products when you have VC backing). This means we have a solid foundation technically (large-scale deployments in mission critical systems) to now handle wider awareness. Mongo will really help us bring the awareness of Ditto.
3. Right now candidly our permission system is nascent compared to Atlas - a webhook fires from Ditto to allow you to integrate into external identity systems and apply permissions. The focus with enterprise meant we targeted use-cases that didn't have too much dynamism in their permissions and data models, so you will find our system naive comparatively. This is a top priority where we will be adding built-in dynamic permission functionality that is similar to Device Sync later this year. You can read more on our system here: https://docs.ditto.live/auth-and-authorization/data-authoriz...
Thanks for the reply! Will definitely be looking into Ditto as a migration option. What would you say the main benefits are of going schema-less? In this context does it more mean that the client is responsible for serializing/de-serializing into the correct data structures? I'm browsing the docs already but any extra information would be helpful, particularly around handling evolving data needs, import/export, client sync, etc.
Yeah the client has to serialize/deserialize - think of the DB as a mini Mongo where you insert JSON into collections as the mental model. Reason for this is that in our experience, sync is easier when the system is schema-less because the nature of the system ties folks across teams, so this means the schema tends to live above each individual client (iOS, Android, backend, etc and in larger orgs those are each separate teams). Furthermore, advances such as Codable in Swift and other patterns means client devs are fairly used to handling this with JSON/REST patterns anyway.
More similar is that Ditto uses a query-based sync approach - this was an area I am particularly passionate about and helped push at Realm. The challenge with this vs. strict channels is then scalability of the backend system - but we have solved these scalability challenges in several ways.
Most prominently, internally Ditto works different than at least my understanding of how Realm Sync worked originally (it might have evolved more under Mongo). We use CRDTs to handle the conflict resolution, so any JSON inserted into Ditto, ends up being a nested CRDT structure on disk. This enables the same predictive conflict resolution, but its a crucial trade off compared to other approaches.
First, CRDTs enable P2P sync where no server is needed to mediate the system. This opens up use-cases that Ditto powers where mobile devices sync over Bluetooth and P2P WiFi even without a device accessing the internet. Furthermore, it also opens up more scalability on the backend because the server nodes themselves can communicate P2P.
At a more fundamental level this is a trade off of using extra metadata (CRDTs include more context like version vectors and such to know how to merge with each other) compared to Realm's original approach of Operational Transformation which is an algorithmic approach. We felt that the metadata approach was holistically better because of the access to new use-cases and scalability meanwhile there are clever ways to make the metadata cost not a real-world issue (i.e. compression in various ways). Conversely, the algorithmic approach is limited to a client server architecture and has computational scalability issues.
All in all, we are very sympathetic to transition costs, but are confident folks will find Ditto can meet the same and more capabilities in Device Sync. Our current challenge is going to be introducing a pricing scheme to support the broader set of Mongo users. To date, we have been very focused on larger enterprise deployments (gotta ensure the bills are paid!) so we will be creative to ensure anyone transitioning is not affected by pricing if they like us!
Adam (CEO of Ditto) here, happy to answer any questions! Really excited about this partnership and the potential to combine our unique P2P capability (powered by CRDTs) with Mongo Atlas.
Our belief is that edge devices are super computers that shouldn't be treated as dumb clients. These devices can store data, perform advanced computation, and connect to each other directly - which is what Ditto enables.
This doesn't mean the cloud is going anywhere, centralized systems still play a major role, especially in large scale AI workloads (where Mongo's vector search means you don't need other tools). However, the cloud is not guaranteed from connectivity failures to backends issues (like CrowdStrike outages).
Ditto + Mongo means you can build resilient applications that leverage the best of the edge and cloud!
Query-based replication works when you know what the user probably wants to have in advance (e.g. a device in a warehouse needs records for that stock in that warehouse, not others). But that's still push.
You still need pull on demand access when a user opens any random item where we don't know in advance what they probably want (e.g. a discussion board scenario).
