#dev 2025-06-30

2025-06-30 UTC
kleb6, NaomiAmethyst and [aciccarello] joined the channel
#
[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
#
aaronpk i suppose the other indieweb relevance to MCP is that I've blogged about it on my website :D
troojg, bugliker00 and bugliker0 joined the channel
#
[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
#
doesnm [snarfed]: wait, it's openid, not oidc. They are not compatible
#
[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.
#
doesnm [tantek]: at least json wins
jak2k and [KevinMarks] joined the channel
#
[KevinMarks] Not to mention SQL
#
doesnm POST /sql
#
[KevinMarks] JSON doesn't do well at representing graphs as it doesn't have a pointer model, so you need to establish an id linkage or url linkage
rosipov8 joined the channel
#
trwnh aren'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...
#
trwnh well, 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
#
trwnh basically 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)
#
trwnh the 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
#
trwnh like, 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
#
trwnh makes 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?
#
trwnh so at the end of the day you could just say the "universal API" is HTTP, really...
#
trwnh the 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
#
trwnh (although admittedly, parsing HTTP headers is a bit gnarly at times)
barnaby joined the channel
#
aaronpk Yeah 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
#
aaronpk It does remind me a lot of the Web 2.0 days of the early "open API" wave where everything was going to have an API
ttybitnik joined the channel
#
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
#
capjamesg [edit] [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
#
capjamesg Oh wait there are no items in the list 🤦
#
[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
bugliker0 joined the channel
#
[aciccarello] I think it's less interesting as a technology "Universal API" and more interesting that it's encouraging more open API development
#
[aciccarello] Like the last thing aaronpk said
#
[artlung] (muses idly of what `/feed-deaths` and `/api-deaths` pages would look like)
#
[KevinMarks] AtomPub was another one of the unifying api models for lists of things
#
[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.
[manton] joined the channel
#
[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] unrelated, capjamesg re that granary q, sounds like it's ok after all...?
#
[tantek] Don't forget XML-RPC!
#
[snarfed] lol yes
#
[snarfed] but actually pls can we forget it
#
[tantek] JSON also (re)creates accessibility and internationalization problems (in contrast to HTML)
#
[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
#
[snarfed] but still, fair
#
[manton] XML-RPC is going to be with us for a loooong time. 🙂
#
[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)
#
[KevinMarks] ProtoBuf?
#
[KevinMarks] I'm so old I remember *IFF
#
[snarfed] heh
#
[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
Pixi__ joined the channel
#
[tantek] To trwnh's point, XML-RPC is a great example of "you could have just used HTTP"
#
[tantek] [manton] I think XML-RPC will die off as services that support it and send user/pass via it die off (replaced by HTTP + OAuth)
#
[tantek] XML-RPC when used as a write protocol, creates security problems
#
[snarfed] what is XML-RPC still widely used for? anything? blog clients? and are those still widely used?
#
[manton] [tantek] Oh yeah, I actually agree. It’s mostly MarsEdit that is keeping XML-RPC alive at this point.
#
[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.
#
[snarfed] it supports XML-RPC for...clients? anything else?
#
[manton] Nope, just clients. Any new web admin stuff uses the JSON API, I think.
#
[manton] Related from a week ago: https://x.com/photomatt/status/1937485239208579195
[schmarty] joined the channel
#
[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
#
[manton] [tantek] Pretty much, yes. I know Daniel has looked at Micropub already for MarsEdit.
#
[tantek] I vaguely remember that and some of the shortcomings he found from the perspective of his use-cases.
#
aaronpk waits for the inevitable "but micropub is too old" complaints
#
[tantek] lolwut
#
[tantek] aaronpk, or Micropub becomes like HTML and HTTP 🙂
#
aaronpk first public working draft was almost 10 years ago! https://www.w3.org/TR/2016/WD-micropub-20160128/
#
[manton] [tantek] Yep, but all of those shortcomings have been addressed now with Micropub extensions. It’s just a matter of doing the work.
barnaby 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] might be worth starting to brainstorm which extensions meet that "bar" (whatever the bar is) for a Micropub 1.1
#
[tantek] and a good test of that bar could be, does it include enough for MarsEdit?
gRegor, [KevinMarks] and [aciccarello] joined the channel
#
[manton] That is a great idea! I would love to see a 1.1 that incorporates many of the extensions that people are using.
barnaby, doesnm, ttybitnik, Lilly2010, KE0VVT and troojg joined the channel
#
[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.
#
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
troojg and mahboubine joined the channel