Çekirdek sunucu

openplate-core bir günlüğü cihazlar arasında taşır. openplate içinde hesapları tutan tek hizmettir. Kendi imajı, veritabanı ve sırrı olan ayrı bir dağıtılabilir birimdir ve tarayıcı onunla doğrudan konuşur. Uygulama sunucusu onun adına hiçbir şeyi vekil olarak iletmez ve hiçbir eşitleme rotasına hizmet vermez.

Günlük, cihazdan çıkmadan önce şifrelenir. İstemci yerel depoyu serileştirir, gzip ile sıkıştırır, rastgele bir veri anahtarıyla AES-256-GCM kullanarak şifreler ve sonucu tek bir opak ikili veri bloğu olarak yükler. Veri anahtarı, parolandan türetilen bir anahtarla sarmalanır: parola Argon2id ile uzatılır ve HKDF ile bağımsız dallara bölünür. Bunlardan ikisi cihazda kalır ve sana ait olanın sarmalamasını çözer, üçüncüsü ise oturum açma kimlik bilgisi olarak gönderilir. Bunlar ebeveyn ve çocuk değil kardeştir, bu nedenle kimlik bilgisine sahip olmak anahtar hakkında hiçbir şey ortaya çıkarmaz.

İşletmeci bir kurtarma anahtarı tutar. Kayıt sırasında uygulama bir kurtarma kodu oluşturur ve veri anahtarını bununla sarmalar. Kodu openplate-core servisine gönderir, o da kodu kendi gizli anahtarıyla kilitler. Postayla gelen parola sıfırlamasının boş bir hesap yerine günlüğünü geri getirmesini sağlayan şey budur. Bu durum aynı zamanda bir örneğin yöneticisinin o örnekteki bir günlüğü geri yükleyebileceği ve prensipte okuyabileceği anlamına gelir. Kendi barındırdığın bir örnekte o yönetici sensin. sync.md bu dengeyi eksiksiz açıklar.

Sunucunun şifreli metin dışında ne gördüğü PROTOCOL.md §9 içinde açıkça belirtilmiştir: bir e-posta adresi, ikili veri boyutu, yazma sıklığı ile zamanlaması, sürüm numaraları ve KDF parametreleri.

İsteğe bağlı araştırma konsolu, aynı sunucuda kendine ait ayrı hesaplar tutar. Ne zaman açık olduğunu Eşitleme, uygulamada neden yer aldığını ise ADR-0008 açıklar.

Üstveri konusunda dürüst olmak gerekir, çünkü "uçtan uca şifrelenmiş" ifadesi genellikle "sunucu hiçbir şey bilmez" şeklinde anlaşılır:

• Blob boyutu ve dolayısıyla hesabın yaklaşık ne kadar veri tuttuğu. Sıkıştırma, bunu eskisine göre daha belirsiz bir sinyal haline getirir, gizlenmiş bir sinyal yapmaz.
• Yazma sıklığı ve zamanlaması: bir cihazın ne zaman ve ne sıklıkla eşitlediği.
• Sürüm numaraları: blobVersion, envelopeVersion ve saklanan sürüm sayısı.
• Parola kaydı için KDF parametreleri ve tuz (salt). Bunlar sır değildir, giriş yapmadan önce yeni bir cihaza sunulmak üzere bulunurlar.
• Bir hesabın kurulumu tamamlayıp tamamlamadığı (anahtar kayıtları var mı) ve daha önce hiç eşitleme yapıp yapmadığı (bir blobu var mı).
• Hesabın kendisi: bir e-posta adresi, isteğe bağlı bir görünen ad, bir rol, günlük bir yapay zeka kotası, bir askıya alma anı, bir kimlik doğrulama doğrulayıcısı (parolanın anahtarlı özetinin anahtarlı özeti, bkz. §5.8), kurtarma kanıtı üzerinde aynı yapıda ikinci bir doğrulayıcı ve hesabın KDF parametreleri. Adres, dünyadaki bir kişiyi tanımlar, 0.5.0 sürümünün kaldırdığı ve 0.6.0 sürümünün bilinçli olarak geri getirdiği bir kişisel veri sınıfıdır (ADR-0005): bir kuruluştaki kişiler, davetlerinin ulaştığı adresle tanımlanır, çünkü bir ay sonra da bilecekleri tanımlayıcı budur.
• Hesabın mühürlenmiş KURTARMA KODU (accounts.recovery_code_escrow, §3.1). Okuyucunun üzerinde durması gereken liste girdisi budur. SERVER_SECRET alt anahtarı altında AES-256-GCM ile şifrelenmiştir, bu nedenle yalnızca veritabanının dökümünü almak onu açmaya yetmez, ancak yönetilen bir kurulumun işletmeni her ikisine de sahiptir. Yönetilen bir kurulumun işletmeni, üzerindeki herhangi bir hesabı açabilir. Bir uç nokta üzerinden veya bu hizmetteki herhangi bir kod yoluyla değil, eldeki sırla o sütunu okuyup istemcinin kendi HKDF'sini çalıştırarak bunu yapabilir. Kendi sunucunda barındırdığın (self-hosted) bir kurulumun işletmeni kendinsin, dolayısıyla eski güvence orada geçerlidir. Bu nedenle barındırılan bir kuruluma güvenip güvenmeme kararı, işletmenine dair bir karardır.
• Bekleyen davetler: Her biri için bir adres, isteğe bağlı bir ad, bir rol ve bir kota bulunur; henüz hesabı OLMAYAN ve onay vermemiş birine aittir. Bir tane üretmek işletmen eylemidir ve DELETE /v1/admin/invites/:id satırı geri çeker. §5.8.3'teki istek kapısının ürettiği bir satır bu şekilde işaretlenir, böylece bir işletmen bunları sayabilir. Bir saat içinde Tamamlanmış bir davet, adresini ve adını kaybeder: Her örnekte iptal edilmiş veya süresi dolmuş bir satır; yalnızca aşağıdaki anahtarlı karmayı tutan TRIAL_ADDRESS_PEPPER bulunan bir örnekte ise kullanılmış bir satır silinir. Çeşni olmadan kullanılmış bir satır adresini korur, çünkü §5.21'deki üye yeniden davet kuralı bunu okur.
• Tarama denemesi, çalıştıran bir örnekte: hesap satırındaki iki tam sayı olan, tanımlanan ve kullanılan ücretsiz taramalar. Yalnızca bir tarama denemesi hesabı için, yapay zeka eylemi başına bir satır: istemcinin seçtiği opak bir kimlik, bir zaman, bir istek sayısı ve bir yanıtın iletilip iletilmediği, 24 saat saklanır ve ardından silinir, asla günlüğe kaydedilmez. Her davet satırı, adresin ikinci bir kopyasını değil, bir posta kutusunun anahtarlı tek yönlü karması (yalnızca operatörün elinde bulunan bir sır olan TRIAL_ADDRESS_PEPPER altında, §5.8.3'ün deneme anahtarı üzerinde HMAC-SHA256) taşır.
• Bir hesap silindikten sonra, tarama denemesi yürüten bir örnekte: adres ve ad, o posta kutusuyla ilgili her davet satırından kaldırılır ve yalnızca hesap bir denemeye sahip olduğunda posta kutusunun tek bir anahtarlı karması saklanır, başka hiçbir şey saklanmaz: ad yok, kimlik yok ve tek bir tarih, yani silinme anı yer alır; satırın sonlanmasını sağlayan da budur. Aynı posta kutusunun ikinci bir deneme almasını engelleyen şey budur. İşletmecinin sırrı olmadan özet geri döndürülemez veya bir adres listesiyle eşleştirilemez. Bir süpürme işlemi, GDPR Madde 6(1)(f) yasal dayanağıyla (ücretsiz taramaların kötüye kullanılmasını önlemede meşru menfaat, bir avukat tarafından incelenmemiştir, ADR-0010) bu andan TRIAL_HASH_RETENTION_DAYS sonra (varsayılan olarak 365) onu siler. Tarama denemesi vermeyen bir örnek hiçbir özet tutmaz. Tarama denemesi yürütmeyen bir örnekte davet satırları, §5.21 üye yeniden davet kuralı uyarınca bir silme işleminden sonra adreslerini korur.
• Yapay zeka kullanımı: UTC günü başına hesap başına bir tamsayı, 90 gün boyunca saklanır ve ardından silinir (§5.20). Bu bir sayıdır, asla bir günlük kaydı değildir: istem yok, yanıt yok, model yok, günün ötesinde bir zaman damgası yok. Bir işletmen, bir hesabın sayaçlarını gün be gün bir şerit olarak okuyabilir (GET /v1/admin/accounts/:id/activity), bu bir kişinin bir sağlık uygulamasını ne zaman kullandığına dair üstveridir ve tam da bu nedenle sınırlandırılmıştır.
• Açmış olan hesaplar için Topluluk nabzı (§5.23, ADR-0007): öğünlerin, fotoğrafların, kalorilerin ve protein gramlarının kurulum genelindeki günlük toplamları, katkıda bulunan hesap başına günlük bir satır ve bir hesabın şu anda oruç tuttuğunu belirten kısa ömürlü bir mevcudiyet satırı. Toplamlar hiç kimseyle ilişkilendirilemez; katkıda bulunan satırı ve mevcudiyet satırı ilişkilendirilebilir ve yalnızca "bu hesap bugün katkıda bulundu" ve "bu hesap oruç tutuyor" derler. Günlük toplamlar ve katkıda bulunan satırları 30 gün saklanır, mevcudiyet son sinyalden 30 dakika sonra sona erer ve rotalar hiçbir hesap kimliğini günlüğe kaydetmez. Bunu hiç açmamış bir kişi hiçbir şey göndermez ve bunların hiçbirinde yer almaz.
• Bildirimleri açmış bir cihaz için Bir push aboneliği (§5.24, ADR-0008): push servisi uç noktası, şifreleme yaptığı iki anahtar, sınırlandırılmış bir user agent dizgisi, bir IANA saat dilimi, bir yerel ayar, yerel günde yakalama bildiriminin gönderileceği dakika, en son gönderildiği yerel gün, cihazın en son görüldüğü yerel gün, uyanmak istediği an ve bugün gönderilenlerin sayısı. Bunlar birlikte, bu kişinin kabaca ne zaman uyanık olduğunu, dünyanın kabaca neresinde bulunduğunu ve wake_at üzerinden bir orucunun ne zaman bittiğini gösterir. Bu sonuncusu, pulse'ın varlık satırıyla örtüşür, aynı orucun sürdüğünü belirtir; ADR-0008 bu ilişkiyi keşfedilmeye bırakmak yerine açıkça adlandırır. Hiçbir bildirimin metninden tek bir kelime bile SAKLANMAZ: her push bir tür taşır. Cihaz abonelikten çıktığında, push servisi cihazı sahiplenmeyi bıraktığında veya hesapla birlikte bu satır silinir.
• Bunu isteyen bir örnekte (§5.15.1) Sağlık verisi onayı: Kişinin kabul ettiği metnin sürümü ve bu servisin bunu kaydettiği an, hesap satırında iki sütundur. Kişinin bir sağlık uygulaması kullandığını ve işletmenin bu verileri işlemesini kabul ettiğini belirtir; işletmen bunu gösterebilmelidir. Bir işletmen tarafından görülebilir (§5.20), hiçbir rota bunu temizlemez ve silme sırasında hesap satırıyla birlikte gider.
• Bir kişinin en son ne zaman bir işlem yaptığı: Giriş yapıldığında ve vekil üzerinden tamamlanma sağlandığında yazılan, ancak bir belirteç yenilemesi ya da eşitleme sorgusuyla bilerek yazılmayan accounts.last_seen_at; bu sayede "bir istemci çalışıyordu" yerine "biri işlem yaptı" anlamına gelir. Bir işletmen tarafından görülebilir (§5.20) ve silme işlemi sırasında hesap satırıyla birlikte gider.
• Yasal bildirimler (POST /v1/legal/declarations, her örnekte bir iptal veya cayma bildirimi): kişinin yazdığı ad, adres, sözleşme referansı, neden ve tarihler, ulaştığı zaman ve varsa eşleştiği hesap. Europe/Berlin saatine göre sayılarak ulaştığı yılı takip eden üçüncü takvim yılının sonuna kadar saklanır ve ardından saatlik temizlik tarafından silinir: 2026-09-21 tarihinde alınan biri, Berlin saatiyle 2030-01-01 00:00 itibarıyla silinir. Hesabı silmek bunu daha erken silmez; satır hesap kimliğini kaybeder ve kalır, çünkü kişinin ne beyan ettiğinin kaydıdır. Makbuz e-postası, normalleştirilmiş adres başına üç, gönderici ağı başına LEGAL_DECLARATION_RECEIPTS_PER_NETWORK_PER_DAY (varsayılan olarak 10) ve örnek başına LEGAL_DECLARATION_RECEIPTS_PER_DAY (varsayılan olarak 200) ile sınırlandırılmıştır. Her sınır, geriye dönük 24 saatlik süre için geçerlidir. Bellekte tutulan ağ sayısı hariç, toplamlar bu satırlardan sayılır. Sınırı aşan bir bildirim yine de saklanır, iletilir ve işletmeciye gönderilir ve 202 aynı kalır. Makbuz adı, sözleşme referansını veya nedeni asla tekrarlamaz; bunları yalnızca işletmecinin kopyası taşır.
• Oturum meta verileri: Kaç etkin oturumun bulunduğu, her birinin ne zaman oluşturulduğu ve belirteçlerin en son ne zaman döndürüldüğü veya iptal edildiği. Belirteç değerlerinin kendileri yalnızca özet olarak saklanır.
• SYNC_RESEARCH ayarlanmış bir dağıtımda Çalışma grafiği (§5.18): Hangi hesabın hangi çalışmaya, ne zaman, ne sıklıkla ve her defasında ne büyüklükte katkı sağladığı. Buradaki bir kenar, "bu kişinin sağlık verileri Y çalışmasında yer alıyor" anlamına gelir ve aşağıdaki bakım kenarıyla aynı sınıfta, sağlığa bağlı kişisel bir veridir. Bu kaçınılmazdır bir durumdur ve vazgeçme işlemi bunun kanıtıdır: Bir katılımcının satırını silmek için onu bulmak gerekir, hesap silme işlemi onu da kapsayarak basamaklanmalıdır ve hem karşılaştır ve takas et hem de suistimal kontrolü hesap üzerinden anahtarlanır. Sunucuyu körleştiren bir şema bunlardan birini bozar ve trafik analizi zaten bu körlüğü ortadan kaldırır, bu nedenle yarım yamalak kaçınmak yerine bu durum açıkça paylaşılır. Araştırmacı bu eşleştirmeyi asla almaz (§5.18 hesap kimliği taşımaz), vazgeçme işlemi kenarı kalıcı olarak siler ve geriye yalnızca bir takma ad bırakır, bayrağın bulunmadığı bir dağıtımda ise çalışma grafiğini tutacak bir tablo yoktur.
• SYNC_SHARING ayarlanmış bir dağıtımda Paylaşım grafiği (§5.16): Hangi hesabın hangi diğer hesaba okuma izni verdiği, bu iznin ne zaman tanımlandığı ve izin verilen tarafın bunu ne zaman kullandığı. Bu bir ilişki grafiğidir, bu servisin bildiklerinin gerçek bir genişlemesidir ve özelliğin geliştirildiği ortamda (bir hasta ve diyetisyeni), bu grafikteki bir kenarın kendisi de sağlığa bağlı kişisel bir veridir, çünkü birinin bakım altında olduğunu gösterir. Okuma yetkisi vermek için gereken asgari veri budur; izin veren taraf satırı oluşturduğu ve izin verilen taraf kendi tarafını silebildiği için her iki uç da onay verir; izin iptal edildiğinde kenar kalıcı olarak silinir ve hesaplardan biri silindiğinde basamaklı olarak kaldırılır. SYNC_SHARING değerini ayarlamayan bir dağıtım böyle bir grafiği saklamaz ve bunu koyacak bir tablosu da yoktur.

• SYNC_FEEDBACK ayarlanmış bir dağıtımda (§5.25, ADR-0006) Bildirilen tahminler: bir kişinin bildirmeyi seçtiği her bir girdinin sayısal verileri, cihazda hala varsa tabak fotoğrafı, hesap kimliği, onay kaydı ve varış zamanı, hepsi okunabilir durumdadır. instance.feedback.retentionDays boyunca saklanır, ardından bir temizlikle silinir ve hesapla birlikte giderler. Bir işletmeci bunları §5.20 aracılığıyla okuyabilir ve bir fotoğrafın her okunması günlüğe kaydedilir. Bu bayrağın bulunmadığı bir dağıtımda tutulacak hiçbir bildirim ve fotoğraf bulunmaz.

Yukarıdaki meta verilerden bilinemeyecek olanlar: ne yendiği, ne zaman yendiği, ne kadar yendiği veya veri yükünün içindeki diğer herhangi bir şey. Yukarıdaki iki kayıt bunu açığa çıkarır. Mühürlü kurtarma kodu, SERVER_SECRET değerini de elinde tutan kişiye günlüğün tamamını açar ve bildirilen bir tahmin taşıdığı tek girdiyi gösterir.

Bir bulut örneği INSTANCE_MODE=managed ayarlayabilir (bkz. configuration.md). Bu tek bir şeyi bildirir: bir kuruluş bu bulut örneğini çalıştırır, kişilerini e-posta ile davet eder ve her birine günlük bir yapay zeka kotası verir. openplate-core bunu taşıyan bileşendir, eşitleme için zaten tuttuğu hesap aynı zamanda kotayı da tutar, böylece ikinci bir bağlantı adımı ve ikinci bir kimlik bilgisi olmaz.

Tarayıcı için hiçbir şey değişmez: kotası olan oturum açmış bir hesap, openplate-core'un sunduğu yapay zeka vekili üzerinden tarama yapar; bu, istemcinin eşitleme için zaten konuştuğu servisin aynısıdır. Arkasındaki şey içinse openplate-core bir istemcidir: ya bir bulut sağlayıcıya ya da kendi openplate-inference konteynerine işaret eder. Çıkarım hesaplama katmanıdır, openplate-core yönetilen bir bulut örneğindeki çoklu kiracılık katmanıdır ve birlikte çalışırlar: çekirdek sunucu hiçbir model barındırmaz ve taramaları kendisi yanıtlamaz.

Fotoğraf yolundadır, dürüst maliyeti de budur. Önlem ise bir ayar değil, kodun kendi özelliğidir: günlükleyicinin alan türü yalnızca ilkel değerleri kabul eder, bu nedenle bir gövde asla günlük satırına ulaşamaz ve üst sunucu hata dizgeleri günlüğe kaydedilmeden veya döndürülmeden önce temizlenir. Bir organizasyonun üyeleri veriyi değil, harcamayı paylaşır; vekil sunucuya ulaşan bir tabak fotoğrafı bir kez okunur ve saklanmaz.

Kota para birimini değil istekleri sayar. Bir yönetici tüm örneği günlük olarak da sınırlayabilir (AI_INSTANCE_DAILY_LIMIT) ve sağlayıcıdaki üst anahtarda harcama sınırı yine de gereklidir.

Bir yönetici örneği uygulamadaki /admin üzerinden çalıştırır: kişiler ve kotaları, davetler, etkinlik, bildirilen tahminler ve Besin ögeleri ekranının hangi referans değerlerini alıntıladığı.

Geçmiş

Ağustos - Eylül 2026 arasında bu, openplate-gateway adında ayrı bir servisti: tek bir üst anahtarı tutan ve her üyeye kendi günlük kotasına sahip bir opk_… belirteci veren, OpenAI uyumlu küçük bir vekil sunucuydu. M192 (Eylül 2026) bunu openplate-core içine birleştirdi: artık tek bir hesap hem günlüğü hem de kotayı taşır; böylece ikinci bir servis, ikinci bir davet bağlantısı ve dağıtılacak ikinci bir kimlik bilgisi kalmamıştır.