xinbenlv

Thanks, that's helpful. Do you use gitleaks or other library to do pre-commit protection? @toomuchtodo

And if you are interested in testing it please let me know

Thanks @pjjpo, exactly. My bad to confuse people, no we don't put real prod-prod credentials in .env. We use mechanisms to ensure separation of secrets. Thank you for saying that it's a simple yet effective implementation. If you try it and let us know your feedback.

That's a good idea too, thanks for the suggestion

Good points

I am interested, that said, there are many memory and context services. What makes this one different?

It happened multiple times to me on Claude Code too, next time I caught it I will try to record its history and show it here

My question is not about on or off storage, is more about when you give agent access, it assume the environment agent runs is safe

What if you simply need to give them access. E.g if you want them to do code review you have to at least give them code repo read access. But you don't know if the environment where agent runs will be compromised

is the permission device+client based or role based?

Any prompt injection attack could by pass this by simply do a base64 or any encoding, I guess?

Xoogler here too, yes, we used Gmail and Google Workspace at Google.

You can search for an exact string if you use quotes. I think you can also filter out logos

We use infiscial and other mechanism but hey, wouldn't it be nice to have one less square inch of attack surface?

Haha thanks my friend, well said.

Exactly, exactly

Thanks, glad you liked it!

Wise @X friends: why have major authentication providers like @auth0 and @ClerkDev and @Google / @LinkedIn SSO have not supported "Multi-Signer Authentication": instead of a single signer, simply ask for more signers to authenticate an action (login, or approval).

For example, when traditionally a low risk action would be validated with a single email confirmation, a high risk action (change password, add passkey) will require two different email confirmation with two different email domains, and plus, a user can add N email addresses (trusted contacts) and a min M of these email addresses can help approve a change of email.

This is not very much different from what @safe achieves already using smart contract, but is massively backward compatible with emails

This will massively reduce the chance of social engineering.

Let us know if you hate the idea too

So people ask us a lot why we bother to Tokenize domains and what's the value. We finally took a time to write it down

Thank you for your response. Without this MCP, I couldn't directly install MCP servers without having to find the right command / url and add them to the mcp.json. If you know which MCP server already supports this feature, I would love to use.

Congrats Erik. We are launching something that support x402 soon. DM'ed you on LinkedIn

Here are a few links for folks to poke around:

Our source code made public on Github: https://github.com/d3servelabs/d3caf

Ethereum mainnet deployment address (Implementation V1) https://etherscan.io/address/0xcfbd663cf943ace12646a0f92c53f...

See the full list in the HackMD note.

Looks pretty nice. What tech stack behind it if you mind sharing?

## Final words (first batch of answers)

Thank you all for your passionate conversations. Your criticize and defending are all super valuable and inspiring to us.

Thank NoZebra120vClip@, bawolff@, spaceman_2020@, justsomeadvice0@, duskwuff@, 8organicbits@, mvid@, greenthrow@, sacnoradhq@: you helped us think harder with your criticizing comments and questions.

World177@, sowbug@, everfree@, 40four@, peyton@ crote@ yieldcrv@, xk_id@ Thank you for your defending, your inspiration and your support! It means a lot. We also look forward to collaborate with you if interested.

oskarw85@: That's simply not true. Even if the underlying mechanism is the public-private key pair most owners do not use it with signing in mind.

OP: Society with and without "phones" are foundamentally different. The introduction and adoption of cryptography into daily life is at this level.

In the beginning, we probably could only attract a small group of adoptors. But the monthly active editors of Wikipedia is only O(100000) and the number of editors that actively review and "like" edits are even smaller, around O(1000). This is the scale of users that have made great impact on Wikipedia and the world's knowledge.

Considering most Wikipedia editors are under-employed guitarists and retired house painters deciding on the veracity of details about local history events and obscure scientific niches, this doesn't help much.

OP: that's true, for majority editors. But just like Balaji says in his Network State book, it only take a small group of people to start something big. We just need early adoptions from some subset of editors and hopefully if it's useful, other poeple will see it and begin using it.

FreeTrade@: I'm interested to see an integration of wikis and web-of-trust. This looks to be a step in the right direction.

OP: yes, thank you! That's what we see in common!

@crote: Heck, I'm having trouble seeing what makes this better than a Facebook Like!

Yes it's pretty much the same as Facebook Like, except that the accounts are decentralized so could never be banned. Also you could have a group of people "like" an edit as a group (shared identity).

@mvid: I work in crypto, and even I ask, what makes this better than GPG?

OP: two points.

1. It helps harness the help from EVM wallet's adoption. Most people don't know how to use GPG. Most GPG tools aren't built with mind of regular user as target audience.

2. We could soon see on-chain identities, and organizational relationships linked to it. E.g. one could use ERC-1271 to have a contract attest to a signature.

@8organicbits: Can I create 1000 empty wallets and endorse bogus edits 1000 times? It's really easy to create empty wallets at scale. What value does an endorsement like that have?

In a centralized setup, e.g. facebook and twitter, that's what they have suffered from.

In decentralized setup, however, it's possible that different reader will use different algorithm provider. If an algorithm provider uses something like PageRank/EdgeRank kind of graph-random-walk based reputation algorithm, 1000 empty wallets who doesn't have reputation will not increase any reputation of the edits they endorse.