🚨Alpha alert 🚨 @tempo is zojuist een paar minuten geleden live gegaan. Met de lancering van de mainnet lanceren ze ook de specificatie van het Machine Payments Protocol. Ik heb vroegtijdige toegang gekregen tot de specificatie en heb enkele eerste gedachten. Ten eerste is de MPP-specificatie een nieuwe, alternatieve kijk op de 402 "request for payment" http-code. Het verschilt fundamenteel van x402 doordat het de Facilitator uit de architectuur verwijdert. Aan de ene kant is het meestal een goed idee om een tussenpersoon uit de stroom te verwijderen. Aan de andere kant verplaatst het de verwerkingslogica die door de Facilitator wordt afgehandeld naar de Server van de handelaar. De tijd zal leren of dit goed of slecht is, maar mijn gok is dat er een overtuiging is dat de serverzijde agent in staat zal zijn om de stromen van de handelaar te optimaliseren, zodat het hebben van een derde partij daarvoor overbodig is. Nu moeten we afwachten... De MPP-specificatie ontwerpt ook voor verschillende betaalmethoden naast stablecoins, inclusief ondersteuning voor fiat via creditcardbetalingen, wat ik een overwinning vind. Daar komt bij dat er een PSP-agnostische benadering is, wat ik een dubbele overwinning vind. Handelaren zouden in staat moeten zijn om elke betaalmethode te kiezen die ze willen, verwerkt door welke betalingsdienstaanbieder ze ook willen. Nu over de vragen die ik heb. Ten eerste heeft de specificatie voor kaartbetalingen een nieuwe versleutelingsmethode waarbij de Server (d.w.z. de Handelaar) de decryptie van de payload van de Klant controleert. Helaas roept dit vragen op over PCI-naleving. De Server controleert niet hoe de Klant (de koopagent) zijn kaartdelegatie beheert. De voorgeschreven route lijkt DPANs te zijn, maar ruwe PANs vallen ook onder de reikwijdte op basis van de specificatie. Omdat de Server de CHD-payload niet controleert, kunnen ruwe PANs worden versleuteld en naar de Server worden gestuurd voor doorsturing naar de PSP van de Server. Dit zou op zijn beurt vereisen dat de Server PCI-naleving heeft, tenzij het kan garanderen dat de payload altijd alleen een DPAN is. Het vereisen dat elke Server PCI SAQ A of, nog erger, SAQ D-naleving heeft, is niet schaalbaar. Ten tweede stelt de specificatie meerdere betaalmethoden in, maar lost het transacties niet wereldwijd op. Hoewel dit normaal lijkt, is het, naar mijn mening, voor agent-naar-agent betalingen om op te schalen, optimaal om een wereldwijde grootboek te hebben waar alle agenten op kunnen aansluiten. Waarom vraag je? Om verschillende redenen, maar een specifieke reden is identiteitsvaststelling. De identiteit van de agent zal deels worden gekoppeld aan statistische modellering op basis van transactiegeschiedenis. Het hedendaagse voorbeeld hiervan is kredietrisicoprofilerings. Echter, compartmentalized transactie-netwerken zullen leiden tot uiteenlopende transactiegeschiedenissen, wat problemen zal veroorzaken bij het proberen om gedrag op te lossen. Gefeliciteerd aan iedereen die betrokken is, inclusief onze partners bij Visa en VGS. De ruimte maakt enorme vorderingen. Dingen beginnen samen te komen, en we kijken ernaar uit om de stukken op hun plaats te zetten.