Continuing the discussion from Solid vs ATProto:
@kjetil.kjernsmo.net is bringing some 
here, but I’m sure he agrees that, rather than devolving into a fight, we’re fully capable of having a reasoned discussion about tech-stack trade-offs here.
Even though I don’t really know what it means, I do love the sound of this:
use the verbs of the HTTP protocol for resource manipulation
Is that something Solid did well?
My main point of interest in this debate is about the tech allowing us to express intent
With HTTP verbs, we can differentiate between mutation types, is it creating or destroying for example. This is something that is missing in Lexicon today, but is trivial to include by adding a single field.
One concrete example of how this might be used, with auto form generation from lexicon, we could present the user with an extra warning/confirmation for destructive actions
Absolutely! I wouldn’t delve too much into it, AT Proto has made a choice in the area, and that’s fine, and tech fights are not worth fighting at this point. If I was out to fight a fight over, I would just go somewhere else. 
But since you ask, I guess I’d take this as a little opportunity to talk about my (old) world, and where I was hoping it would go.
Solid did it, but it didn’t do it all that well, because if it had done it well, the Solid Protocol document wouldn’t need to exist. And the AT Protocol documents wouldn’t need to be so extensive either.
So, this goes back to the oft-quoted and mostly misunderstood architectural style of REST (OMG, I just noticed that Roy Fielding’s dissertation, which contains the definition of REST, has been taken offline after 25 years!). One key concept of REST is “Hypermedia as the engine of application state (HATEOAS)”, where the point is that you shouldn’t rely on external, “out of band” specs to define the interaction that happens, once you have established the ground rules, the application should just need to look at the messages being passed back and forth to know what to do.
If you can do that, then the application can much better adapt to changing conditions, you literally would just need to change the response of the server, or the request of the client, and you can change how things work. To me, that’s extremely compelling.
So, the question is what is part of the ground rules. I was perfectly willing to accept HTTP as part of that. In HTTP, you have the verbs HEAD, GET, POST, PUT, PATCH, DELETE , OPTIONSand so on, and you have many other facilities, caching, authentication, determining the uniqueness of a response, a lot of stuff. Solid attempted to use all that to the fullest, and while it didn’t get there, it got pretty close. However, it did so in a spec that I co-edited/co-authored, not in the in-band messaging that I would rather have liked to explore. So, in Solid, how to use HTTP was part of the ground rules.
To go beyond that, you’d need an expressive language to express what the application could do. There was a philosopher-mathematician, I forgot his name, who demonstrated some time in the 70-ties that everything could be expressed with triples, so I thought I’d go with RDF for that. So, in 2018, before I was hired to work on Solid, I wrote up some code and a text to do something around that.
What I envisioned was that you’d get to develop with View Source again, that you wouldn’t need long specs, and at some point, you’d get a logic based AI that could help you, without resorting to training an AI using methods that scorch the earth and boils the ocean.
So, REST, Solid and my vision share the idea that you are operating on a thing, and the methods of the protocols are the verbs you use, but the Solid spec doesn’t satisfy other key aspects of the architectural style. Fielding himself made a blog post on such topics, and I think you’d see that many of his points also apply to AT Protocol.
Now, what I do realize, of course, is that when something has been quoted as much as REST have, but still has been misunderstood as much as it has, it is quite likely that the idea is too alien to people. People aren’t able to get stuff done with it.
So, basically, from what I’ve seen, in AT Proto, you get methods, stuff like getProperty. And then, you map that directly onto a URL and there you go. Simple and straightforward, I get that. In Solid, you’d probably need at least a couple of layers of abstraction to get there, and this kind of abstraction would reside entirely on the client side. To me, I guess I was too much “some of you might die, but that is a sacrifice I’m willing to make” with regards to that 
since my concern was elsewhere, and I thought that just a sufficient investment in DX would take care of it. But in REST, the existence of endpoints and the presence of verbs in URLs really gives it away, that’s not REST.
But that’s OK. RPC has been around for ages, and while it hasn’t been talked about that much, it has demonstrated that it works. And you can certainly work towards hypermedia on the top of an RPC protocol too.
So, I’m clearly not the right person to be very opinionated on the DX of end-user facing systems, and with the flurry of apps in this ecosystem, it is clear that it is a major hit of this community. But thanks for the question, it was nice to just write down some thoughts around it.
Live service & capabilities discovery could be a cool thing to introduce, especially if we can motivate it with specific usecases. It would be quite simple to exchange Lexicons or their identifiers via some protocol to dynamically learn about an endpoint.
My remaining observations – to give my bonafides, I once tried to build a unified REST/HATEOAS communications framework so I’ve certainly been there.
Using HTTP verbs more vigorously is definitely on the table if it solves an actual problem. For instance, the idempotency semantics of PUT is great if we need it. I also think the QUERY verb that’s under discussion could be a big value to AT Proto.
That said, as yall know, our style of pathing is way off for the resource-centric model of REST, and I’m skeptical that introducing links in the responses which point toward other available state transitions would add utility.