[artlung]Sounds weirdly like universal dial tone to me. In that sense I look forward to Captain Crunch's famous whistle to be deployed. _of course, maybe I'm misunderstanding the utility of this, maybe it already has security layers built in I don't know about._
bugliker00, bugliker0, kleb6, Nick2, kleb61 and jak2k joined the channel
[snarfed]it feels overstated. these pitches for universal APIs come along pretty regularly. COM/CORBA, XML, SOAP, GraphQL, etc. the catch is that you always still have to understand what each service is, what it does, how you can use it, etc separately, and write your client code for it separately, regardless of whether you're using MCP or GraphQL or anything else as the transport
[snarfed]the "universal" part of MCP is less the API transport and more the fact that you can speak the same human language to an LLM and have it fetch from any number of services via LLM
[snarfed]...but even then, a human has to describe what they want each time. we're just more comfortable with that, maybe, than with writing new client code each time
[tantek][snarfed]++ haha I was just thinking the same thing and then read what you wrote. Exactly, every 5-10 years someone reinvents a "universal API" or something similar, it gets super-hyped, and then never delivers on the promise. I'll add to that list DCOM / SOM / DSOM (adjacent to CORBA), SGML before XML, WSDL / WS-* (adjacent to SOAP), RDF, JSON, JSON-LD etc.
trwnharen't those all just serialization / data formats? i don't get what's supposedly "universal" about any of those things, except perhaps their ability to serialize arbitrary generic data...
trwnhwell, you could look at it as negotiating parameters, i guess... depending on which parameters you choose, you end up with something slightly different but serving the same purpose
trwnhbasically a protocol is the sum total of all of those negotiated parameters and the behaviors you can trigger (either at the machine level or at the human level)
trwnhthe thing that annoys me is that you usually end up with a matroshka doll of messages-in-messages, with overlay networks being built on top of existing networks
trwnhlike, consider the typical header-body structure, with data/content going in the body, and metadata going in the headers. you can just take that head+body and make it be the body of a new message... ad infinitum
trwnhmakes me somewhat unironically think we could just be passing around raw HTTP messages instead of treating HTTP as a wrapper for some more bespoke messaging protocol. aren't HTTP messages also basically RFC 822/etc style internet messages?
trwnhthe only way this could break down is if your information modeling for a "message" doesn't map cleanly onto the concept of header metadata + body content
aaronpkYeah it's definitely a stretch to call it a universal API, but one thing that could come out of it is more things having APIs in the first place
[artlung]yeah, that's what I find. press release lists, certain kinds of groups of written pages generate rss. I've added a few more patterns for platforms / rss feed urls at https://smorgasborg.artlung.com/?filter=rss
[manton]On MCP, I’ve had someone ask for support in http://Micro.blog too. The more I think about it, the less I want to allow automatic posting via MCP, just in case AI loses it’s mind. But seems really useful for querying posts so you could use AI for searching and summarizing your blog.
[snarfed]trwnh yes some of those are/were just data formats, but they were pitched as enabling the same kind of universal interop. but many of them are actual protocols like MCP: SOAP/WSDL, COM/DCOM/CORMA, GraphQL, SoLiD, etc
[snarfed]I'm definitely partial to the idea that more things will add MCP that otherwise wouldn't have added APIs at all. maybe so! I wonder how many of those there will be, but still, agreed. you still have to actually understand and use each service independently though. you don't get interop with new things literally for free
[snarfed]not entirely fair comparisons, HTML is designed to be both human and machine readable, JSON is mainly designed to be machine readable, developers themselves notwithstanding
[tantek][snarfed] I think the "designed to be machine readable" is a trap because format that has strings ends up with user visible strings in it (which is where JSON fails i18n)
[snarfed]serialization formats like protobuf, JSON etc and RPC frameworks like GraphQL, gRPC, etc are useful, and are often (and more honestly) not pitched as "universal APIs"
[tantek]And similarly any format that has URLs (by way of having strings) is going to have user visible image URLs and thus needs to reinvent alt text m, or forgets to like 99% of JSON vocabs and thus you get an accessibility problem
[manton][snarfed] WordPress still supports XML-RPC too. When they added their custom JSON API, it wasn’t straightforward to switch native clients to it for various auth reasons. Not sure it’s better now.
[tantek][manton] so basically if we can convince MarsEdit and WordPress to support Micropub in core (i.e. without plugins) then no more need for clients or servers to support XML-RPC?
[KevinMarks] and NaomiAmethyst0 joined the channel
[tantek][manton] oh wow that's great to hear! Perhaps on the standards side then we need to incubate a Micropub 1.1 that builds-in those well-adopted extensions
[tantek]micropub << Brainstorming: Consider both a 1.0.1 release that incorporates errata (with no new features), and a 1.1 update that incorporates popular micropub extensions, and at least those that [[MarsEdit]] requested in feedback.
Loqiok, I added "Brainstorming: Consider both a 1.0.1 release that incorporates errata (with no new features), and a 1.1 update that incorporates popular micropub extensions, and at least those that [[MarsEdit]] requested in feedback." to the "See Also" section of /Micropubhttps://indieweb.org/wiki/index.php?diff=102583&oldid=101907
[aciccarello] I thought this article on MCP was intriguing as someone not in the LLM space. "MCP: An (Accidentally) Universal Plugin System" https://worksonmymachine.substack.com/p/mcp-an-accidentally-universal-plugin
[snarfed] it feels overstated. these pitches for universal APIs come along pretty regularly. COM/CORBA, XML, SOAP, GraphQL, etc. the catch is that you always still have to understand what each service is, what it does, how you can use it, etc separately, and write your client code for it separately, regardless of whether you're using MCP or GraphQL or anything else as the transport
[tantek] [snarfed]++ haha I was just thinking the same thing and then read what you wrote. Exactly, every 5-10 years someone reinvents a "universal API" or something similar, it gets super-hyped, and then never delivers on the promise. I'll add to that list DCOM / SOM / DSOM (adjacent to CORBA), SGML before XML, WSDL / WS-* (adjacent to SOAP), RDF, JSON, JSON-LD etc.
[KevinMarks] Not to mention SQL
capjamesg [snarfed] I am running into an issue converting Squarespace RSS feeds to as2 with granary. This code returns an empty list: https://gist.github.com/capjamesg/930059b0d2ca438ccdd4781c784e0604
[artlung] yeah, that's what I find. press release lists, certain kinds of groups of written pages generate rss. I've added a few more patterns for platforms / rss feed urls at https://smorgasborg.artlung.com/?filter=rss
[manton] On MCP, I’ve had someone ask for support in http://Micro.blog too. The more I think about it, the less I want to allow automatic posting via MCP, just in case AI loses it’s mind. But seems really useful for querying posts so you could use AI for searching and summarizing your blog.
aaronpk first public working draft was almost 10 years ago! https://www.w3.org/TR/2016/WD-micropub-20160128/
Loqi ok, I added "Brainstorming: Consider both a 1.0.1 release that incorporates errata (with no new features), and a 1.1 update that incorporates popular micropub extensions, and at least those that [[MarsEdit]] requested in feedback." to the "See Also" section of /Micropub https://indieweb.org/wiki/index.php?diff=102583&oldid=101907