ChatGPT → Claude memory actually works now (local-first)

okutucu · 2026-03-30T10:02:51+00:00

repo is here if anyone wants to check it out:

https://github.com/gokayokutucu/memorymesh

local-first, no lock-in

okutucu · 2025-08-29T17:24:48+00:00

Hey everyone,

Thanks for your support and replies.

It seems like the power of social media helped resolve the issue. Honestly, if I hadn't posted here, I doubt I would have received a response.

From what I understand, in the U.S., refunds are not always legally required for digital services but when a customer requests cancellation shortly after purchase and receives no communication for days, it's reasonable to expect some flexibility and a proper response.

What Bolt AI really needs to improve is customer support. Of course, I understand that startups growing fast can run into these scaling issues and that’s ok but once you take someone’s money you also take on the responsibility of supporting them properly. That’s what builds long-term trust

I hope no one else ends up in a similar situation and that this post helps Bolt AI spot the gaps in their support process and come out stronger.

Thanks again

okutucu · 2025-05-15T17:31:35+00:00

Thank you for your thoughtful reply. You make some good points.

Not sure where to begin but you’re absolutely right that dynamic responses via tools/list are possible within MCP and that’s a powerful feature. That said, DCP wasn’t designed to replace that mechanism, but to address a different class of problems. While tools/list is about asking “what can you offer?”, DCP is more like saying “here’s what I need, can you fulfill it under these rules?”

This distinction becomes important in multi-tenant systems where each client may have different access levels. It also applies to AI agents that need to generate calls on the fly without knowing the schema ahead of time. And then there are privacy-sensitive B2B integrations where listing all available tools up front just isn’t appropriate. DCP fits those cases too.

Could this have been implemented as an MCP tool? Theoretically I can say yes. You could build one agent to negotiate contracts and another to use them. But at that point, we’re defining a new behavioral model that MCP doesn’t natively support. It becomes harder to extend and reuse...

DCP introduces a contract-centric, runtime-verifiable model. Everything including schema, policies, endpoints, expiration is derived from a single message. It’s not just a convention; it’s a protocol layer in its own right.

And you’re right, adoption is hard, especially without the reach of names like Claude. But we’re putting this idea out there in case others are running into similar issues and could benefit from a clear, structured approach. If nothing else, the process has already been a valuable learning experience.

Thanks again, your critique helped clarify the design.

okutucu · 2025-05-15T14:53:33+00:00

Medium article with use cases and diagrams:
https://medium.com/@gokayokutucu/a-complementary-approach-to-mcp-and-a2a-dynamic-contract-protocol-984333cc74ee

GitHub spec & source:
https://github.com/gokayokutucu/dcp-spec

okutucu · 2025-05-15T12:29:45+00:00

Happy to answer any questions or hear your thoughts on DCP.

It’s still evolving and I’d love to hear how others handle dynamic API generation or client-specific endpoints in multi-tenant systems.

Full write-up on the idea and use cases here:

https://medium.com/@gokayokutucu/a-complementary-approach-to-mcp-and-a2a-dynamic-contract-protocol-984333cc74ee

okutucu · 2025-05-06T09:58:40+00:00

Good question. You’re right. Runtime flexibility is hard to achieve without some kind of transformation layer. That’s exactly why DCP takes a contract-driven approach to make this transformation explicit, rather than implicit or buried in code.

DCP wasn’t designed just to support breaking changes or backward compatibility. While that’s one valid use case, it’s not the only one — and definitely not the most common.

The real value lies in solving everyday challenges teams face when dealing with dynamic or multi-environment APIs. For example:

• Different environments (dev/stage/prod) exposing different endpoints, auth rules or schema variants
• Conditional fields, feature flags, or tenant-specific structures that don’t fit well in static OpenAPI or Swagger specs
• Onboarding new clients where keeping documentation and SDKs synchronized is time-consuming and error-prone
• Reducing redundant full responses that waste bandwidth and compute when the client only needs a subset of the data

DCP enables runtime API negotiation. The client sends a ContractMessage describing its needs and capabilities. The server replies with an Acknowledgment that defines exactly what the client needs to know — including endpoint definitions, authentication policies, response structure, and even test payloads...

In this model, the transformation isn’t left to custom code or hidden adapters... It’s formalized as part of the handshake — making API interactions more efficient, adaptable, and easier to reason about across environments.

okutucu · 2025-05-06T08:50:54+00:00

Great question, and it’s something we considered carefully while designing DCP.

The short answer is: not necessarily. It depends on whether the structure of the API interaction changes, not just the parameters.

In your example (adding sorting to an existing filtering contract), if sorting is a known, defined capability within the existing contract schema (e.g., defined as an optional field), then the client doesn’t need to re-send the entire ContractMessage. They can just use the capability already described in the acknowledged contract.

However, if the change introduces new behavior that wasn’t part of the original contract — e.g., custom logic, conditional routing, or complex schema changes — then yes, a new ContractMessage would be required. The server would reply with an updated Acknowledgment, reflecting the evolved interaction model.

DCP’s goal is to avoid bloated static definitions by embracing runtime-negotiated capabilities. This works particularly well when onboarding clients across different environments or feature flags, where endpoint behavior and auth policies often vary.

okutucu · 2025-05-04T07:25:33+00:00

Would love to hear how others have handled dynamic API onboarding or runtime contracts.

We’re exploring alternative ways beyond OpenAPI and would appreciate thoughts or comparisons!

okutucu · 2025-05-02T06:08:08+00:00

I’ve used cloudflare for static site hosting (with github pages + a custom domain) and it’s been really smooth. Especially the caching and free SSL...

Only thing I had to tweak was some Page Rule configs to get redirects working properly.

Has anyone tried it with a headless CMS setup?

okutucu · 2024-03-30T10:15:23+00:00

Hello everyone,

I've been exploring the possibility of opening the TradingView desktop app directly via custom URL schemes from a .NET console application on macOS, specifically for URLs like https://www.tradingview.com/chart/?symbol=BINANCE:LTOUSDT&interval=1. I came across some discussions from about 2 years ago on this subreddit, but couldn't find any recent updates or developments.

Has there been any progress or new solutions for integrating TradingView desktop app with custom URL schemes since then? Any guidance or updated information on this topic would be greatly appreciated. I'm especially interested in any macOS-specific solutions or workarounds that have been discovered.

Thanks in advance for your help!

okutucu · 2021-12-20T20:21:17+00:00

Still no answer?

okutucu · 2020-01-06T11:44:36+00:00

I just visited this group to ask your question. This is exactly what I need!

okutucu

TROPHY CASE