Beszélgetések

GET /threads?folder=inbox. A query átadása ugyanazt a helyi indexet keresi. A sima szavaknak mind szerepelniük kell, és mindegyik lazán illeszkedik, kis- és nagybetűt, ékezeteket és elválasztókat figyelmen kívül hagyva, így a min megtalálja a „Benjamin” nevet. Az idézőjeles kifejezés a kis- és nagybetűn és az ékezeteken túl szó szerint illeszkedik, tehát a "ben jamin" nem találja meg a „Ben-Jamin” alakot. A töltelékszavakat, mint a the vagy az emails, kidobjuk a sima szavak listájából, ha marad még valami, amire keresni lehet. Az olyan operátorok, mint a from:, a to:, a subject:, a label:, az is:unread, a has:pdf, az after:2026/01/31 és a newer_than:7d szűkítik, az OR, a zárójelek és a vezető - pedig kombinálják őket. A címzetteket egyetlen listaként tároljuk, szerepek nélkül, és soha nem tartalmaz Bcc-t, tehát a cc: ugyanazt a mezőt olvassa, mint a to:, a bcc: pedig önmagában semmire sem illeszkedik. A from:me az általad küldött levél, a to:me pedig az a levél, amely a saját címeid egyikét viszi, az aliasokkal együtt, a címzettek között vagy kézbesítési címként.

A szavak, valamint a from:, a to:, a cc:, a subject: és a body: operátor az egyes beszélgetések legújabb üzenetét olvassa: a feladóját, a címzettjeit, a tárgyát és a törzs első 4000 karakterét. A filename: és a has: a teljes beszélgetés minden mellékletét olvassa, a label:, az in: és az is: pedig az egész beszélgetést. A folder továbbra is érvényes, hacsak a lekérdezés meg nem nevez egyet in: operátorral vagy olyan is: értékkel, amely mappa, például is:sent, az in:anywhere pedig minden mappában keres, önmagában és más kifejezések mellett is. A piszkozatlistázás a kivétel: a piszkozatokban marad, bármit is nevezzen meg a lekérdezés.

Azt az értéket, amelyet a keresés nem tud használni, figyelmen kívül hagyjuk, nem pedig szűkítünk vele, így egy elgépelt érték tágítja az eredményt ahelyett, hogy kiürítené: ilyen a category:, a larger:, a smaller:, a size:, a messagesize:, a list:, az rfc822msgid:, a received:, a sent:, a kategóriaszavak, például az is:promotions, az olyan has: szó, amely semmilyen mellékletfajtát nem nevez meg, a high vagy low értéktől eltérő importance:, az olvashatatlan dátum és az a időtartam, amelynek egysége nem h, d, w, m vagy y. Az ismeretlen operátornevet, például a project: kifejezést, sima szövegként keressük. A dátumok a beszélgetés legújabb tevékenységét olvassák, UTC szerint, az after: az általa megnevezett napot is beleértve, a before: pedig kizárva; írd YYYY/MM/DD, YYYY-MM-DD, YYYYMMDD, puszta év, vagy epoch másodperc vagy ezredmásodperc alakban.

A GET /threads/{id} a beszélgetés minden üzenetét visszaadja, nem csak a legfrissebbet, a címkéivel és azzal együtt, hogy van-e benne olvasatlan.

Ez az API se nem titkosít, se nem fejt vissza. Nem tud megnyitni egy olyan üzenetet, amelyet más titkosított, és nem tud titkosítottat küldeni. Azt a kérést, amely titkosítási jelölőt visz, 422-vel utasítjuk el, mert az egyetlen felület, amely ilyet beállíthat, az, amely a kulcsokat tartja, márpedig egyetlen API-kliens sem tart kulcsot. Amit viszont megtesz: FELISMERI a lepecsételt borítékot beérkezéskor, kizárólag a felső szintű Content-Type alapján, és ezt jelzi is az üzeneten.

Az OpenEmail immár maga is tart kulcsokat, és érdemes pontosan megmondani, melyik felét és hol. A postafiók tulajdonosa a böngészőjében generál egy OpenPGP-identitást, és a NYILVÁNOS kulcsot közzéteszi egy címtárban, amelyet más bejelentkezett OpenEmail-feladók fel tudnak oldani. A privát fél abban a böngészőben készül, soha nem kerül ide, és soha nem állítható helyre, tehát ebben az API-ban semmi nem tud semmit visszafejteni, és nincs az az ügyfélszolgálati kérés, bírósági végzés vagy mentésünk, amely kulcsot adna hozzá. A webalkalmazás mostantól KÉPES megnyitni egy PGP/MIME vagy inline PGP üzenetet, ha a kulcs az olvasó böngészőjében van, de ez a visszafejtés a fülön történik, és a nyílt szöveg soha nem íródik vissza: a tárolt üzenet titkosított marad, és ennek az API-nak egyetlen válasza sem viszi a megnyitott szöveget. Az alkalmazás mostantól le tud pecsételni egy új üzenetet a böngészőben, és el tudja küldeni: a szerkesztő a címzettek közzétett kulcsaira titkosít, és a levél PGP/MIME formában megy ki. Ez az API továbbra sem tud semmit lepecsételni, tehát az alábbi mező egyszerre írja le a más által titkosított levelet és az OpenEmail-fülön lepecsételtet.

Ez azért ér meg egy mezőt, mert mi volt az alternatíva. A lepecsételt üzenet nem tárol olvasható törzset, tehát a decodedBody "" értékkel jön vissza, ugyanazokkal a bájtokkal, mint egy olyan üzenet, amelynek valóban nem volt tartalma. Az encryption az, ami alapján a kettőt meg tudod különböztetni, mielőtt bármelyikre reagálnál, és ez a borítékról szóló állítás, nem ellenőrzés: látni, hogy egy üzenet le van pecsételve, nem ugyanaz, mint megnyitni.

{    "object": "thread",    "id": "thread_2f9b…",    "messages": [      {        "id": "msg_7c41…",        "subject": "Q3 numbers",        "decodedBody": "",        "encryption": {          "format": "pgp-mime",          "detectedAt": "2026-08-30T09:14:22.117Z",          "rawRetained": false,          "parts": [            { "index": 0, "attachmentId": "msg_7c41…-0", "role": "version" },            { "index": 1, "attachmentId": "msg_7c41…-1", "role": "ciphertext" }          ]        }      }    ]  }

Csak a három lezárt formátum változtat bármin is, és a változás a beérkezéskor történik, nem ebben a válaszban. Minden, ami a törzset olvasta volna, leáll, ahelyett hogy titkosított szöveget olvasna, és olyan eredményt jelentene, amelyet nem kaphatott volna meg:

• —A törzsben való keresés. Az üzenet üres törzskivonattal kerül indexelésre, így továbbra is megtalálható feladó, tárgy, cím és címke alapján – a benne lévő bármi alapján nem.
• —Az adathalászat-pontozó törzselemzése. A verdikt így is megérkezik, és megmondja, mit nem tudott elvégezni: a risk.signals tartalmazza a body-encrypted jelzést, a risk.aiChecked pedig false.
• —Az AI-szerzőség ellenőrzése, amely inkább nem nyilatkozik, mint hogy találgasson: az aiWritten.level értéke unknown, az aiWritten.skipped értéke pedig encrypted.
• —A szabályok törzsre vonatkozó feltételei. A borítékra és a fejlécekre vonatkozó feltételek pontosan úgy futnak, mint eddig; az a szabály, amely a törzsről kérdezett, kiértékeletlenként rögzül, nem pedig nem illeszkedőként, mert a „nem illeszkedett” és a „nem volt olvasható” két különböző válasz.
• —A naptármeghívók importálása. A meghívó a titkosított szövegben van, és ha a borítékból építenénk eseményt, az hibás bejegyzést tenne egy valódi naptárba.
• —A beszélgetés-összefoglalók és a beágyazások, az egész beszélgetésre. Egyetlen lezárt válasz is elég. Az összefoglaló a modell olvasata a nyílt szövegről, tiszta szövegű metaadatként tárolva, és ez az egyetlen pont ebben a folyamatban, ahol a törzs olyan tárolóba szivárogna, amelyre senki nem gondol törzsként.

Minden, aminek nincs szüksége a törzsre, érintetlen marad:

• —A DMARC, a DKIM és az SPF. Ezeket az Authentication-Results fejlécből olvassuk ki, amelyet a titkosított szöveg nem rejt el, így a titkosított üzenet is valódi hitelesítési verdiktet kap, nem pedig semmilyet.
• —A beszélgetésbe fűzés, a spam iktatása és a tiltólista: mind boríték- és fejlécmunka.
• —A mellékletek. A titkosított szöveget tartalmazó rész az attachments listában marad, encrypted-message.asc néven, ha név nélkül érkezett, és az alábbi végponton keresztül tölthető le. Pontosan ezt tölti le és fejti vissza a böngészőben a webalkalmazás saját olvasója is; egy API-kliensnek, amelynek nincs kulcsa, ez a letöltés marad az egyetlen módja a levél elolvasásának. Nyisd meg olyan kliensben, amelyben van kulcs.
• —Az aláírt üzenet mindebből semmit nem veszít. A fenti ellenőrzések mindegyike tovább fut rajta, és semmit nem tartunk vissza – ezért áll a lezárt formátumok listája háromból, nem ötből.

A PATCH /threads/{id} a read, az addLabelIds és a removeLabelIds mezőt fogadja. Az olvasottság minden olyan backenden címke, amelyet ez a termék támogat, így a read beállítása és a címkék mozgatása egy hívásban determinisztikusan tartja a sorrendet.

{ "read": true, "addLabelIds": ["USER_INVOICES"] }

A GET /threads/{id}/messages/{messageId}/attachments minden mellékletet filename, contentType, size és base64 content mezőkkel ad vissza. A content üres sztring ott, ahol a tárolt bájtokat nem találtuk, ezért dekódolás előtt ellenőrizd a hosszát.