El 2012 vaig escriure un [postmortem per a Plancast](https://markmhendrickson.com/posts/a-postmortem-for-plancast/), una startup a la qual havia passat tres anys. La premissa era senzilla: la gent fa plans, val la pena compartir-los i un feed d'esdeveniments propers de persones en qui confies sortiria a la llum coses que no sabies que volies fer. No va funcionar. La peça va explicar per què. Rellegint-lo dotze anys després, els diagnòstics superficials encara es mantenen. Els plans es fan amb massa poca freqüència per mantenir un hàbit alimentari diari. Compartir plans futurs ofereix bucles de vanitat febles en comparació amb compartir fotos. Els plans caduquen, de manera que qualsevol peça de contingut té hores de vida útil. La majoria dels plans són geogràficament locals, de manera que la majoria dels plans de la vostra xarxa són irrellevants la major part del temps. I el problema més profund: la gent no vol ser conscient d'esdeveniments als quals no van ser convidats personalment. La consciència sense invitació se sent com una exclusió. La majoria de la gent tampoc vol compartir tots els plans amb tota la seva xarxa. Les persones equivocades poden aparèixer o la sala deixa de sentir-se controlable. El que vaig trobar a faltar el 2012 va ser que cap d'aquests eren realment problemes de mecànica del producte. Eren problemes de substrat. El substrat disponible en aquell moment, un feed dins d'una xarxa social centralitzada, era la forma equivocada per a qualsevol d'ells. Vaig intentar dissenyar el substrat amb característiques. El substrat encara era un sostre baix en totes les mètriques. ## Què estava realment malament Un feed és el primitiu incorrecte per compartir plans perquè: - Un feed suposa un flux constant de contingut. Els plans no arriben com un corrent. - Una emissió de recompenses de feed. Els plans necessiten un públic adreçat. - Un canal té una funció de col·lapse. Plancast va triar "el més aviat primer" per data de l'esdeveniment, els canals socials van triar "el més nou primer" per hora de publicació. Sigui com sigui, és un tipus cronològic. Els plans es beneficien de moltes funcions de consulta, i les útils (qui va al vostre gràfic de confiança, què encaixa aquest dijous, qui és a la ciutat) poques vegades són un tipus cronològic. - Un feed fa que cada contingut sigui visible per a tothom que et segueix. Els plans necessiten àmbits. - Un pinso tracta el consum com la superfície de cara a l'usuari. Els plans necessiten composició amb altres sistemes (calendaris, RSVP, trànsit, temps). - Un feed centralitza la mediació. Els plans són inherentment entre persones. Un cop aquesta llista estigui sobre la taula, cada fallada de Plancast que vaig anomenar el 2012 és un símptoma aigües avall. El substrat no va poder expressar el que realment vol ser l'intercanvi de plans. ## El substrat que necessitava El substrat sobre el qual construiria ara té dues peces, cap de les quals no existia en forma utilitzable el 2012. **Estat durador, només d'afegir per a agents d'IA personals.** Això és el que estic creant com a [Neotoma](https://neotoma.io). Cada observació que fa un agent (un contacte afegit, un esdeveniment contestat, una invitació emesa, una assistència confirmada) es converteix en una entitat mecanografiada amb procedència, restriccions d'esquema i un historial immutable. El propi agent d'IA de l'usuari en llegeix i escriu. No hi ha cap gràfic social centralitzat. L'usuari és propietari de l'estat. **Una malla sobirana de llibretes d'adreces i àmbits de confiança.** Per a això serveix [Darkmesh](https://github.com/markmhendrickson/darkmesh) (la meva bifurcació de l'original d'[Anand Iyer](https://www.anandiyer.com/)). Darkmesh permet que una persona publiqui parts adreçables del seu context (contactes específics, grups específics, àmbits específics) als nodes de malla d'altres persones amb consentiment explícit. El consentiment es manté a la vora de la xarxa. L'agent d'un remitent no pot posar un missatge a l'estat d'un destinatari tret que el node de malla del destinatari hagi admès l'abast del remitent. Els agents d'IA personals parlen entre ells a través de la malla. Digueu que es preocupen per la vida de manera duradora al Neotoma de cada usuari. No hi ha cap servidor central que contingui els plans de tothom. ## Com es fa manejable la missió original El pla original de Plancast era: trobades casuals a partir de la consciència compartida dels plans. L'error va ser pensar que la consciència compartida havia de provenir d'un feed. En aquest nou substrat, el mateix to es descompon en diferents treballs. 1. **La ingesta d'esdeveniments és automàtica.** El meu agent ja sap els esdeveniments als quals he contestat a Luma, els esdeveniments del meu calendari, els esdeveniments als correus electrònics de confirmació d'Eventbrite o Meetup. Els escriu al meu Neotoma com a entitats d'"esdeveniment" amb procedència. Mai els escric enlloc. 2. **La compartició està subjecta al consentiment i s'adreça.** Quan responc a alguna cosa, el meu agent pot marcar els àmbits que haurien de saber que hi vaig. Aquestes no són publicacions de feeds. Es tracten observacions que viatgen a través de la malla només a persones els nodes de les quals han admès el meu abast. 3. **El descobriment és una consulta, no un canal d'informació.** La superfície més natural de "el que està passant al meu món" no és un flux. És una pregunta que faig al meu propi agent. *Qui en la meva malla de confiança anirà cap a on en les properes dues setmanes. Quin d'aquests esdeveniments s'adapta a la meva nit d'aquest dijous. Qui és a la ciutat que no he vist en un any.* Cada consulta es calcula en el moment de la recuperació sobre el meu Neotoma més els àmbits que hagi admès la meva malla. No hi ha alimentació. 4. **Les invitacions són de primera.** Aquesta és la part en què va insistir la peça del 2012 i la part que s'han omès la majoria dels intents de producte. ## Com haurien de funcionar les invitacions Plancast tenia invitacions explícites, però eren manuals. Es van asseure a sobre d'un pla que els vostres subscriptors ja podien veure. El pinso encara era la primera superfície. Una etiqueta, una menció o metadades que et marcaven tenien la mateixa forma: la visibilitat de l'ambient va ser primer, el toc personal en segon lloc. Se suposa que una invitació real invertirà aquest ordre. En aquest substrat, una invitació és una entitat mecanografiada en el propi estat del destinatari. Aproximadament: ``` invitació remitent: contact_id destinatari: contact_id event_ref: event_id àmbit: "1:1" | "grup_petit" | "conjunt_co_assistent" note_to_recipient: cadena (obligatori, no buida) relation_basis: cadena (per què aquesta persona, per què aquest esdeveniment) slot_budget_used: nombre sencer (pressupost per esdeveniment) expires_at: marca de temps conditional_on: predicat de quòrum opcional procedència: agent / font / marca de temps ``` D'aquesta forma se segueixen algunes coses. **El substrat es nega a lliurar si la malla no ha admès l'abast de l'emissor.** Això mata les invitacions de massa freda a la velocitat de la màquina a l'única capa on es poden matar: la vora de la xarxa. **Els pressupostos d'invitació per esdeveniment obliguen a la selectivitat.** Cada esdeveniment té un nombre reduït i configurable d'espais d'invitació que un remitent pot gastar. El substrat, no la força de voluntat, imposa "no feu foc a la vostra llibreta d'adreces". La tensió de la vanitat contra la selectivitat del 2012 es converteix en un paràmetre del substrat. **Treu amb autorització prèvia és el patró dominant.** Quan el meu agent executa la consulta permanent, només veu persones els agents de les quals m'han marcat com a algú a qui els donaria la benvinguda en aquest esdeveniment concret. La intersecció de "qui va a la meva malla" i "qui m'acolliria allà" és molt més petita que "qui va publicar a la meva xarxa". No és un feed. És un índex amb permisos. **El context personal és obligatori a nivell de tipus.** Els camps "note_to_recipient" i "relationship_basis" són obligatoris. El buit no és un estat vàlid. El meu agent pot redactar-los des del meu gràfic Neotoma (últim solapament, context compartit, contactes comuns), però una línia confirmada per humans és l'opció predeterminada. Això és el que apuntava la peça del 2012 quan insistia que la gent vol sentir-se convidada personalment. El substrat fa que la nota personal sigui un requisit estructural, no una cortesia opcional. **El rebuig és silenciós i no s'atribueix.** Els destinataris responen amb "acceptar", "aprovar" o "llapis". Només "acceptar" és visible per al remitent. `pass` es resol amb "sense resposta" sense confirmació de lectura i sense motiu. El destinatari conserva la procedència privada. Podeu auditar la vostra pròpia càrrega social sense exposar-la. **Quòrum és un primitiu de primera classe.** La peça de 2012 va anomenar la procrastinació com un fracàs principal: la gent manté les opcions obertes i es nega a comprometre's abans d'hora. El substrat aborda això directament amb `conditional_on`: "Aniré a X si Aaron i Diwaker també es comprometen". El substrat vigila el predicat i el resol. No hi ha cap rol de coordinador, no hi ha fil de xat en grup, no hi ha flake. **Composabilitat amb el gràfic d'esdeveniments existent.** Quan s'accepta una invitació, l'agent accedeix a la plataforma que és propietari del RSVP canònic (Luma, Eventbrite, calendari) i escriu la reserva real. L'entitat "compromís_d'assistència" de Neotoma es manté canònica per a qui confia en qui va a on. El RSVP de tercers es manté canònic per al lloc i la porta. Dos registres, una font de veritat per preocupació, enllaçats. ## Què estan decidint realment els agents El sistema anterior només funciona si els agents fan un treball no trivial localment. Les dues preguntes, en ambdues direccions del bucle, són concretes. ** Sortint, qui agrairia aquest pla.** Quan el meu agent veu que he contestat alguna cosa, puntua els meus contactes contra l'esdeveniment, no contra mi. Senyals locals útils: - contactes el Neotoma dels quals porta temes compartits o esdeveniments que han participat conjuntament amb aquest, - contactes amb els quals he estat en coses similars durant l'últim any, - contactes que han optat explícitament a una categoria (marca'm sobre música en directe en aquesta ciutat), - contactes l'horari o ubicació dels quals observat se solapa amb la finestra de l'esdeveniment. L'agent produeix una llista de candidats classificada, mai un disparador automàtic. Els pressupostos dels espais els inverteixo jo o amb la meva confirmació, i el camp `relationship_basis` s'omple amb la mateixa puntuació perquè puc veure per què se'ls va suggerir una persona abans d'enviar-ho. **Inbound, quins plans que passen a través de la malla val la pena sortir a la superfície.** El meu agent executa la consulta simètrica amb les invitacions entrants i amb les observacions d'assistència ambiental admeses pel meu àmbit. Senyals locals: - Quant recentment i amb quina freqüència he participat conjuntament amb les persones implicades, - si el tema coincideix amb una categoria amb la qual m'he mantingut compromès, - si el meu propi calendari té espai, - si s'està formant un quòrum que m'importa. La majoria dels pings entrants s'arxiven, no apareixen. Els que apareixen vénen amb el paràgraf curt del propi agent sobre per què aquest i no els altres. Les dues direccions són pesades i totes dues es mantenen locals. No hi ha cap classificador central. L'agent de cada usuari calcula amb l'estat que posseeix l'usuari i aquest usuari pot inspeccionar la puntuació. Això és el que fa que l'experiència comenci a semblar una infraestructura que pot actuar en nom vostre sense convertir-se en una plataforma. ## Com evolucionen les relacions tal com s'observa En un feed, el vostre gràfic de relació és majoritàriament estàtic un cop format. Segueix la gent, no els segueix rarament, i tota la resta és un senyal de soroll que la plataforma interpreta per a tu. En aquest substrat la gràfica està conformada per observacions. Cada escriptura mecanografiada mou una relació lleugerament. Una invitació enviada mou la vora en una direcció. Una invitació acceptada ho avança més. La superposició d'assistència registrada per ambdós agents torna a moure més. Una conversa gravada, una nota compartida o una entitat del projecte, tots dos nodes es toquen i deixen una observació a la vora entre dos contactes, amb la procedència i una marca de temps. El contrari també és cert. Les vores es degraden quan no passa res. Un contacte al qual no heu convidat, no heu assistit o no heu escrit en un any és un tipus d'avantatge diferent del que vau veure el cap de setmana passat. La decadència no és la supressió. La història encara està allà per recuperar-la. Però la puntuació de la rellevància de l'agent demà utilitza el pes actualitzat, de manera que un any de silenci costa visibilitat abans que costi la relació en si mateixa. Això inverteix el model d'alimentació de la manera que importa. Els feeds fan del gràfic l'entrada i l'activitat la sortida. Aquest substrat fa que l'activitat sigui l'entrada i el gràfic la sortida. Les relacions evolucionen perquè el comportament és un estat estructurat, no perquè algú va fer clic a "Seguir" una vegada l'any 2014 i des d'aleshores la plataforma ha pretès que l'avantatge encara significa alguna cosa. ## Què no és això Aquest no és un intent de substituir les invitacions d'autors humans. La feina del substrat és fer que una invitació escrita a mà sigui més barata per enviar-la bé, més segura per aterrar i més difícil d'enviar brossa. Cada capa de dalt està destinada a retrocedir l'experiència cap al que el 2012 vaig identificar correctament com la moneda social real: algú en qui confies va pensar en tu específicament. El substrat no pot fabricar aquest pensament. Es pot negar a lliurar substituts. ## Què encara està obert Algunes coses per les quals encara no tinc bones respostes. - Com s'han de denominar i renovar els pressupostos de convocatòria. Per esdeveniment, per setmana, per malla? Lligat a la taxa d'acceptació? - Com es propaguen els canvis d'abast de la malla quan canvien les relacions. Què sembla revocar un àmbit sense cremar una relació? - Interoperabilitat de malla creuada quan els participants executen diferents implementacions de malla. Requereix una capa de protocol fina? - Tractament abusiu quan un remitent admès anteriorment comença a enviar correu brossa. Qui aplica la penalització, el node de malla del destinatari o el substrat en conjunt? - Història de migració per a esdeveniments el RSVP canònic dels quals viu darrere d'un mur de pagament o d'inici de sessió. Aquestes són preguntes reals, però són preguntes de producte i protocol a sobre d'un substrat que ja funciona. No són desconeguts arquitectònics. ## Per què escric això ara Fa unes setmanes, Oo Nwoye va deixar un comentari públic sobre una [peça recent](https://markmhendrickson.com/posts/) sobre la memòria de l'agent i va preguntar, en tantes paraules, si Plancast hauria de ressuscitar per a l'era de l'IA. La resposta és la mateixa que l'anterior. La missió original era correcta. El substrat estava malament. El substrat ara existeix. No crec que la resposta sigui reconstruir Plancast com a aplicació. La resposta és crear invitacions, assistència i àmbits de confiança com a primitius en una capa d'estat personal sobirà, deixar que els agents facin el treball d'ingestió i encaminament i deixar que la mecànica social sorgeixi del fet que una invitació és una escriptura escrita a un estat durador en lloc d'un esdeveniment de feed ambiental. Si has construït o estàs construint alguna cosa en aquest barri, m'agradaria parlar-ne.