It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon.
My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".
It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon.
My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".
It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon.
My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".
It's not so much about what you _can do_ but about the messaging and posturing, which is what drives the adoption of standards as a social phenomenon. My team's been working on implementing MCP-agents and agents-as-tools and we consistently saw confusion from everyone we were selling this into (who were already bought in to hosting an MCP server for their API or SDK) for their agents because "that's not what it's for".
Understanding the limitations is a complicated thing in tech. You can finnangle most systems into doing mostly anything, as inefficient as that may prove to be.
The question then becomes up to what point is it "a reasonably better than most others" solution. And that's a question of an understanding of a field, not a space in the field.
That's the point. Understanding complex things is what experts are supposed to do.
> You can finnangle most systems into doing mostly anything
"most" is doing a lot of heavy lifting here and I think the point you're making isn't discrediting my point. Sure you can hamfist a lot of things into working but an expert should know when to use better tools. Being able to identify what would end up as a very hacky solution from one paradigm but could be efficient and/or elegant in another is what an expert should be able to identify. Essentially, are they able to reduce technical debt even before that debt is taken on?
> an understanding of a field, not a space in the field.
Would you mind clarifying the difference? I agree these are different things but I'm not sure why understanding the limitations would imply not having narrower domain knowledge. Sure, in ML knowing the advantages of convolutions over transformers and vise versa is good. But if you're working on LLMs, ViTs, or anything else it is still good to know what the limitations of transformer models are, and specifically what attention can and cannot do. We should be able to get more and more narrow too. An expert will be able to understand the nuances of specific evaluation methods: metrics, measures, datasets, and other forms of analysis. Being able to discuss nuance and detail is how you determine if someone has expertise or not. IME it tends to be pretty easy to identify experts (even in other fields) due to their ability and frequency of discussing nuances.
Take this with a grain of salt, as I run a startup in the industry.
Blockchain has taken a weird path. It started with Bitcoin offering something genuinely new - a Byzantine fault-tolerant mechanism for decentralized value exchange without trusted intermediaries. But the industry has drifted toward "web3" hype where the technology often isn't necessary.
Companies pick tech stacks for all sorts of reasons beyond technical merit - vendor relationships, development velocity, legacy system compatibility, and UX considerations all factor into these decisions.
Truth is, most blockchain companies today are solving problems that could be handled just fine with traditional databases and APIs. The industry is shifting toward abstraction layers that hide the consensus mechanisms anyway, focusing on user experience instead.
The project mentioned probably doesn't actually need a blockchain backend for what it's doing, except maybe for tradable collectibles on an ERC standard.
It is wise to be suspicious - spending even a small amount of time near the "web3" space will make attentive person suspicious of scams and parlour tricks.
I use the network to host the webxr experiences, which are bundled wasm files, from unity. All of the code lives on the blockchain so, in this sense, i really couldn't do without it.
If you are referring to blockchain-specific functionality, then this is largely true, however i have implemented some demostrations of the consensus mechanism being used from inside an immersive space. This is really to illustrate that it is possible, rather than try to sell you a meme coin.
In the near future I expect to be using the ICP for a lot more, however, since it provides some rather interesting technical opportunities. It is wrapped around something called a 'network nervous system' which acts as a sort of administrator for proposals, so your point about abstraction is accurate, but this is the case with any large vendor.
I choose to build on the ICP because it is more secure and straightforward for my particular stack, plus it has a lot of potential, despite the noise. I've implemented webrtc messaging to keep the cost of normal multiplayer data transfer as low as possible, because consensus is expensive and the network runs on a pay-per-use compute model.
I'm offering a new route, outside of big tech, if you don't consider Unity a menace, which i acknowledge that some do. I am taking an admittedly more radical stance, by including the hosting in this.
Now that I have the context, I find what you're doing super interesting, and well thought out. And greatly value the passion you're building it with as well.
I want to clarify, my message wasn't intended as a dig at what you are doing - especially since I didn't actually look into it at all before writing my reply.
By definition, and especially when explained with enough detail, anything that we do couldn't be done with a different tool, in the sense it'd have to be done differently.
What my comment was meant to address was the original comment's question regarding the value of doing something "on-chain". Mainly because it's something that I've been thinking about a lot, being a founder as well in a similarly-hyped vertical.
At it's core, blockchains are a database, and so any high level goal - beyond the composability/interoperability of on-chain primitives through tokens and shared state - can be achieved without a blockchain.
However, there are many reasons to leverage the position of a blockchain project beyond the technical _need_ for a DLT.
The VC environment might be attractive to some -leveraging the network effects of a sufficiently decentralized network, tapping into ecosystem incentives and growth programs, personal alignment with the moral values typically associated with decentralization, personal connections in the industry/vertical, etc.
All that to say; no one asks why you're using a relational database or a graph database with as much suspicion or caution as they do why you're putting your stuff on-chain, and while that makes sense because of the... unique circumstances of DLTs, there's a lot more nuance to it from a business perspective than just asking yourself the "is it a grift?" question.
I guess what i wanted to get across was that ICP is considerably more than a database, but tbh it's a massive rabbit hole, unless you're already into cryptography. I'm impressed by the foresight and scale of it though.
I thinks it's also the first thing i would call an AI governor, and there is a whole liquid democracy protocol that's pretty well thought out, imo
It's just surprising that the number's that large.