Yes you are perfectly right. Our product pushes users to be selective on the tables they give access to a given agent for a given use-case :+1:
The tricky part is correctly supporting multiple systems which each have their own specificity. All the way to Salesforce which is an entirely different beast in terms of query language. We're working on it right now and will likely follow-up with a blog post there :+1:
Hi, you are right that things can go sideways fast. In practice, the data that the typical employee needs is also quite simple. So there is definitely a very nice fit for this kind of product with a large number of use-case that we do see provide a lot of value internally for employees (self access to data) and data scientist (reducing loads).
For complex queries/use-cases, we generally instead push our users to create agents that assist them in shaping SQL directly, instead of going directly from text to result/graphs. Pushes them to think more about correctness while still saving them tone of time (the agent has access to the table schemas etc...), but not a good fit for non technical people of course.
Hi, this is a fair concern. We're super early and working on a proper privacy policy as we speak. But we also provided some color about how we handle your data on our Discord. Copying it here:
```
The privacy section on the landing README remains true. We just send your requests to OpenAI and store them for debugging purposes but we don't fetch or store anything else than what is required to process your requests of course. XP1 being opensource you can also look at the code if needed, but happy to answer any question
In short:
- Requests (including the text dump of tabs you select) go to the Dust main platform
- They are processed as part of a Dust app whose Run object is stored
- The LLM query is sent to OpenAI (retention policy 30 days, not used for training)
- The response is tored as part of Dust's Run object
- The response is streamed back to the client
```
Copilot actually knows a bit of Lean and can be helpful when formalizing stuff. But it does not get the critical feedback we get from the formal systems (as it's not designed for formal systems).
It would be interesting to eval copilot on the same benchmark as I'm pretty sure it can close some of the proofs still.
It takes a lot of CPU (lean side) on top of GPU (neural side) indeed. But technically, when properly parallelized, it takes no more than 1-2h to crack the hardest problem we've cracked so far.
This is definitely something that we'll be looking into more closely in the future. Our old and busted `gptf` tactic was a good start but we can do much better!
Ah sorry, it's is also definitely possible. The documentation lists the endpoints but it's still very WIP (the doc, not the endpoints): https://settle.network/documentation/
You can also refer to the source code[0] but that requires a bit more effort.
To interact with m.settle.network you would have to signup first using the command line (that's the easiest, to get your key, though doable over curl as well as you rightfully point out)
These are only pointers, but happy to answer any question async over email at [email protected] as well!
That's an interesting thought. I'm not sure I would consider a precious metal a currency because its value is driven by its intrinsic value more than trust. But I do agree that they can be used "as" a currency that is indeed entirely decentralized. Their use online would require trusting services that store them and allow their transfer between accounts which, quite interestingly, maps quite well to the mint model proposed in Settle.
I agree that pure credit networks left with no supervision have been quite bad historically, but it also appear in our new online world as one of the less cumbersome way to move value at scale. What changed since then I think is the amount of information we have on each actor of the credit network which may lead to other outcomes at scale. Also sub part of the network may be quite safe, as an example the subnet that allows BTC wallet users to pay on Stripe merchants with one hop through gdax or any other exchange.
The tricky part is correctly supporting multiple systems which each have their own specificity. All the way to Salesforce which is an entirely different beast in terms of query language. We're working on it right now and will likely follow-up with a blog post there :+1: