spolu

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 ```

Completely agreed with that. We'll revisit if needed but we don't expect it to be too much of an issue at this stage.

Our goal is to gather marginally more usage to learn more about productivity use-cases using LLMs.

Here's the email we sent to our users as we removed the paywall: https://twitter.com/dust4ai/status/1633484243228585988

Dust XP1 runs on a Dust app. You just need a "history" input parameter that gets injected at the right place. Does that make sense?

The real value will accrue as the assistant become more personalised as users use it.

Completely agreed! I believe I’ll open source the app in the coming days.

This is before anything else an exploration at this stage.

Some additional context here if interested: https://twitter.com/spolu/status/1602692992191676416

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!

Sorry, late reply. Indeed settle.network expired and is now owned by another party. Sorry for the ensued confusion.

Completely agreed.

(30k proofs to be precise, valid and test are each 1k)

Really like how V-trace reduces to A3C when on-policy. Quite elegant, but it’s unfortunate they don’t give results on continuous tasks.

I wrote that a few weeks ago: https://spolu.now.sh/notes/bitcoin_gmail_keybase.html

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 stan@stripe.com as well!

[0] https://github.com/spolu/settle/tree/master/mint/endpoint

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.

If you head to settle.network you have examples available using the command line until also available.

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.

Very good question. The cost. I wanted to explore/play with a system with free transactions, which is only achievable interestingly without a global blockchain to maintain.

Hi! I just responded on your original comment.

Hi! I work at Stripe on our Bitcoin solution.

We do not send funds back to the originating address but instead allow merchants to programmatically supply a refund address or alternatively handle this part for them by contacting the customer over email to provide a refund address to send the over-payments to.

Hope that clarifies this particular point.

Additionally, to compute over-payments, we rely on Coinbase notifying us of the amounts received on a receiver bitcoin address. In that instance Coinbase erroneously notified us that they received BTC .00231463 (~$5 at the time) instead of BTC 0.1154481, leading to our overpayments logic to not be triggered.

We're investigating with Coinbase on what happened on their end and we'll make sure that the root cause gets fixed.

I was part of the PBL lab at Stanford which was doing a bunch of research in that space. I think the major benefit is remote collaboration ala whiteboard and replay of course.

Agreed with everything that was said here. I personally think it's better to post multiple times than to post with a vote ring. The latter is unfair to the community while the former is not annoying since they just come and go through new

The datapoints are definitely interesting. Thanks for sharing what you use!

Yes this is intended to be used with an audio link.

Thanks! Great feedback. I'll make sure to make it clearer.

Thanks!! You can email me at stan@stripe.com

I've read new Chinese regulations and financial sector getting into it despite the ETF being refused... also speculation I guess!