Prodhuar në BE, dhe ku ndodhen të dhënat tuaja

Ku ndërtohet Nessie, ku ndodhen të dhënat tuaja dhe çfarë kontrolloni kur e instaloni vetë.

Kush e ndërton dhe sipas cilit ligj

Nessie është ndërtuar nga UnlikeOtherAI s.r.o., një shoqëri e regjistruar në Republikën Çeke dhe që vepron sipas ligjit çek.

Kjo faqe përshkruan se si është ndërtuar softueri dhe ku funksionon. Nuk është deklaratë përputhshmërie: Nessie nuk mban asnjë certifikim sigurie, dhe asgjë këtu nuk duhet lexuar si i tillë. Cilat të dhëna personale përpunohen dhe mbi çfarë baze trajtohen në politikën e privatësisë, që është një faqe më vete.

Ku funksionon produkti i hostuar

Nessie Cloud funksionon te ofruesit evropianë të hostimit — Scaleway, Hetzner dhe të tjerë. Zgjedhim shërbimin më të mirë që ofron secili ofrues, ndaj pjesë të ndryshme të produktit mund të funksionojnë te ofrues të ndryshëm, të gjithë në Evropë.

Çdo detaj më i saktë se kaq — një vend, qytet ose qendër të dhënash e caktuar — nuk përmendet qëllimisht këtu, sepse do të vjetrohej pa e vënë re askush.

Vetë-hostimi ia lë zgjedhjen në duart tuaja

Vendi ku funksionon një instancë e vetë-hostuar është cilësim i vendosjes në punë, jo cilësim i produktit. Rruga me një makinë të vetme është një stack Docker Compose që e vendosni në një makinë që e zgjidhni vetë. Në pemën Terraform për një cloud të menaxhuar, rajoni është një hyrje pa asnjë vlerë të paracaktuar: aty nuk mund të hamendësohet asgjë, ndaj aty nuk ka asnjë vlerë të paracaktuar, dhe baza e të dhënave, kova e ruajtjes së objekteve dhe shërbimet ndjekin të gjitha rajonin që ju caktoni.

Dy detaje strukturore kanë rëndësi për të njëjtën pyetje. Radha e punëve dhe transporti në kohë reale janë të dyja PostgreSQL — nuk ka Redis dhe nuk ka message broker në rrugë, pra nuk ka një sistem të tretë që duhet vendosur diku. Dhe ruajtja e objekteve është e pajtueshme me S3 dhe jo e lidhur me një ofrues të vetëm; vendosja e referencës ekzekuton MinIO në një kontejner, në një rrjet privat pa hyrje të vetën. Pjesët që duhet të jetojnë diku janë baza e të dhënave, ruajtja e objekteve dhe dy shërbimet Node, dhe të gjitha jetojnë andej ku i vendosni ju. Si ngrihet e gjithë kjo shpjegohet në faqen e instalimit.

Çfarë mban Nessie — dhe çfarë qëllimisht nuk mban

Identiteti nuk kopjohet

Me hyrjen përmes UnlikeOtherAI, ofruesi i identitetit menaxhon dhe ruan identitetin e njerëzve — faktorët e vërtetimit, profilet, anëtarësimin në organizatë dhe në ekip, dhe ftesat. Nessie është palë mbështetëse, jo një sistem i dytë identiteti. Kjo është po aq vendim për të dhënat sa edhe për arkitekturën: një identitet që Nessie nuk e ruan kurrë është një identitet që nuk mund ta nxjerrë jashtë, ta humbasë ose të dështojë ta fshijë.

Ajo që tabela users mban realisht është identifikuesi i qëndrueshëm i përdoruesit nga ofruesi — çelësi përmes të cilit zgjidhet gjithçka tjetër — adresa e emailit, një pasqyrë jo autoritative e emrit të shfaqur dhe e avatarit, dhe fusha lokale të produktit (preferenca, përemra, një version tokeni që përdoret për të shfuqizuar sesionet). Pasqyra ekziston vetëm që emri dhe fotoja të shfaqen pa një kërkesë për çdo rresht, dhe sinkronizohet përsëri nga pohimet e verifikuara të ofruesit gjatë hyrjes, gjatë ndërrimit të ekipit dhe gjatë rifreskimit të sesionit. Asgjë nuk shpik një vlerë: një person që ofruesi nuk e ka emërtuar mban adresën e vet të emailit derisa ta emërtojë. Hash i fjalëkalimit ekziston vetëm për pronarin fillestar të një instalimi pa asnjë ofrues identiteti.

E njëjta gjë vlen për strukturën. Një organizatë te ofruesi është një organizatë Nessie, e lidhur me id-në e organizatës nga ofruesi; një ekip pa lidhje në anën e ofruesit përgjigjet me 404 TEAM_NOT_LINKED në vend që të kthehet te një hamendësim lokal, dhe një lexim i drejtpërdrejtë i listës së anëtarëve shkon te ofruesi i identitetit dhe nuk ruan asgjë.

Dy pasqyra nuk janë hequr ende, dhe do të ishte e pandershme të sugjerohej e kundërta. Emrat e organizatës dhe të ekipit ruhen ende lokalisht pranë id-ve të lidhjes, dhe rreshtat lokalë të anëtarësimit ende autorizojnë kërkesat e zakonshme midis sinkronizimeve. Heqja e të dyjave është punë e hapur e ndjekur në repozitor, jo diçka tashmë e përfunduar.

Asgjë tregtare

Shërbimi qendror i faturimit menaxhon pagesat. Nessie nuk ruan klient, abonim, faturë, çmim, gjendje krediti, politikë rimbushjeje, pëlqim pagese, pasqyrë llogarie ose gjendje anulimi të ofruesit të pagesave, dhe nuk llogarit tarifa. Lexon vlera të gatshme për shfaqje dhe i tregon.

Sekretet

Për të ruajtur një sekret nevojitet domosdo një kasafortë e konfiguruar. Qëllimisht nuk ka rezervë në bazën e të dhënave dhe nuk ka rrugë me tekst të pastër: pa kasafortë, ruajtja, rrotullimi dhe shfuqizimi i një sekreti kthejnë gabim në vend që të kalojnë te diçka më pak e sigurt. Regjistrimet e vetë Nessie për një sekret nuk mbajnë vlerë, tekst të enkriptuar, çelës apo token kasaforte — vetëm një referencë të errët dhe metadatat e saj — dhe rrugët në kasafortë ndërtohen vetëm nga identifikues strukturorë, kurrë nga emri i një organizate, ekipi, projekti ose personi.

Kredencialet që Nessie duhet t’i mbajë vetë për të vepruar si klient OAuth — kredencialet e konektorëve dhe të kutive postare, sekretet e webhook-ut, materiali i rifreskimit të sesionit, ngarkesat e ekzekutuesit — vulosen në zarfe AES-256-GCM të lidhura me qëllimin, nën një unazë çelësash me version që është rrënjë më vete nga sekreti i nënshkrimit të sesioneve, me procedurë rrotullimi të dokumentuar.

Ekziston edhe një rregull për modelet: një sekret mund të dihet që ekziston dhe mund të autorizohet për përdorim, por materiali i sekretit nuk duhet të hyjë në kontekstin e modelit, në prompte, në argumentet e mjeteve, në rezultatet e mjeteve, në memorie, në embedding, në kërkim, në regjistra ose në mesazhe. Një agjenti mund t’i jepet aftësia të përdorë një sekret. Nuk mund t’i jepet kurrë aftësia ta zbulojë.

Nëse diskjet themelore janë të enkriptuara është veti e makinës ku funksionon një vendosje. Repozitori nuk vërteton enkriptim në nivel vëllimi për vëllimet e bazës së të dhënave dhe të ruajtjes së objekteve, ndaj kjo faqe nuk e pretendon.

Izolimi i qiramarrësve

Nessie është shumë-qiramarrëse që nga dizajni: një bazë të dhënash e vetme, ku çdo rresht i përket saktësisht një organizate dhe çdo tabelë fëmijë mban një organization_id. Izolimi zbatohet në dy vende — klauzola e fushëveprimit që mbart çdo kërkesë, dhe çelësat e huaj të vërtetë mbi atë kolonë, të cilët u shtuan përmes dyzet e dy kufizimeve pasi një auditim i brendshëm gjeti se kolona ekzistonte por pa kufizim në dhjetëra tabela.

Një grup testesh përputhshmërie e mban atë invariant në vend në kufirin HTTP. Ai krijon një sulmues me privilegjet maksimale — një pronar i plotë i organizatës së vet — dhe pohon se çdo lexim kanonik i burimeve të një organizate tjetër përgjigjet me 403, 404 ose bosh, dhe çdo mutacion kanonik refuzohet pa e prekur rreshtin e organizatës tjetër. Ai mbulon kanalet, miratimet, regjistrin e auditimit, trigerat, agjentët dhe lidhjet e tyre, ekzekutimet, projektet, detyrat, fijet, lidhjet, instalimet e rrjedhave të punës, instancat MCP, bazën e dijes dhe alarmet.

Të jemi të saktë për mekanizmin: ky është zbatim në nivel aplikacioni plus çelësa të huaj, jo siguri në nivel rreshti të PostgreSQL (RLS). Nuk ka politikë RLS dhe nuk ka mbështetje shtesë nga ana e bazës së të dhënave, dhe grupi i testeve ekzekutohet kundër një ruajtjeje besnike në memorie dhe jo kundër një baze të dhënash të gjallë, ndaj provon klauzolat e fushëveprimit që shkruan kodi dhe jo SQL-në që ekzekuton një server. Repozitori e thotë këtë në dokumentimin e vetë grupit të testeve, dhe e thotë edhe kjo faqe.

Gjurma e auditimit

Çdo veprim me pasoja regjistrohet: kush veproi dhe në cilën cilësi — person, agjent, shërbim — çfarë bëri, mbi cilin burim, në cilën organizatë, projekt, ekip ose kanal, nëse pati sukses apo u refuzua, pse, dhe id-në e kërkesës, adresën dhe user agent-in me të cilët mbërriti.

Regjistri është vetëm për shtim që nga dizajni dhe nuk ka asnjë mënyrë për të shkruar në të nga jashtë: POST /api/audit-log nuk ekziston, dhe kjo është e qëllimshme. Shënimet janë të zinxhiruara — secili mban një digest SHA-256 të fushave të veta kanonike plus digest-in e shënimit të mëparshëm për atë organizatë — kështu një rresht i ndryshuar ose i hequr e prish zinxhirin dhe zbulohet. Një pronar ose administrator organizate mund ta përshkojë atë zinxhir sipas kërkesës dhe i tregohet ku u prish për herë të parë, nëse u prish.

Dy rezerva të ndershme. Zinxhiri e bën regjistrin të dukshëm ndaj ndërhyrjes, jo imun ndaj ndërhyrjes: nuk ka heqje të të drejtës së shkrimit në nivel baze të dhënash dhe as ruajtje një-shkrimëshe pas tij, ndaj garancia është zbulimi, jo parandalimi. Dhe shënimet ruhen pafundësisht si parazgjedhje — mbajtja e konfigurueshme me eksport përpara fshirjes është e projektuar, jo e ndërtuar. Shënimeve u ndalohet gjithashtu të mbartin sekrete ose trupa të plotë kërkesash, dhe një grup i caktuar emrash fushash të ndjeshme në metadata redaktohet gjatë hyrjes.

Regjistri i kostove

Çdo thirrje e modelit regjistrohet kundrejt organizatës, dhe kundrejt përdoruesit, ekipit, projektit, kanalit, agjentit dhe ekzekutimit nga ku erdhi, me tokenët që konsumoi dhe me koston e raportuar nga ofruesi dhe vlerësimin e vetë Nessie të ruajtura krah për krah. Një metrikë që ofruesi nuk e raporton ruhet si null dhe jo e hamendësuar. Raportet janë të lexueshme nga një pronar ose administrator organizate.

Ky regjistër është telemetri operacionale — sa shpenzoi një organizatë dhe për llogari të kujt. Nuk është faturë dhe nuk është autoritet faturimi.

Palët e treta, kur përdorni produktin e hostuar

Një vendosje e hostuar komunikon me një grup të vogël dhe të caktuar shërbimesh. Trafiku i modeleve dhe kërkimi në web nuk shkojnë drejtpërdrejt te ofruesit: të dyja dalin përmes një porte të vetme të operuar nga UnlikeOtherAI, ku ndodhen ofruesit e modeleve dhe të kërkimit. Hyrja dhe faturimi shkojnë te autentikuesi i UnlikeOtherAI. Kasaforta e sekreteve është e vetë-hostuar pranë aplikacionit. Lidhjet e thirrjeve video të krijuara nga serveri përdorin si parazgjedhje shërbimin publik Jitsi.

Pothuajse gjithçka tjetër është e fikur derisa ta konfigurojë një operator, dhe e thotë këtë në vend që të dështojë në heshtje: llogaritë e lidhura të Google, Microsoft dhe Slack; emaili i agjentit përmes Amazon SES, që një vendosje e ekzekuton në llogarinë e vet pa ndërmjetës; njoftimet push për celular dhe shfletues; konektorët e kërkimit dhe të burimeve të tabelave; shfletuesit në cloud. Vlen të përmenden dy detaje, sepse ndryshojnë ku shkojnë të dhënat:

• Kutitë postare të lidhura mbeten te ofruesi juaj. Posta lexohet drejtpërdrejt nga ofruesi juaj, përmes IMAP dhe SMTP ose përmes hyrjes së vetë ofruesit; Nessie ruan kredencialin e vulosur dhe asgjë tjetër për llogarinë. Një kuti postare që lidhni me kutinë hyrëse të Klientëve është përjashtim: ju kërkoni që bisedat e saj të ruhen pranë çdo klienti, ndaj kopjohen brenda.
• Thirrjet zanore në aplikacion nuk kalojnë përmes Nessie. API-ja ndërmjetëson një kredencial dhe klienti e hap vetë lidhjen e audios. Diktimi dhe thirrjet telefonike janë ndryshe: audioja e tyre kalon përmes Nessie te ofruesit e të folurit dhe të modeleve që e përpunojnë.

Një detaj i inferencës ndjek të njëjtin parim: titujt e nënshkruar të identitetit të thirrësit dërgohen vetëm te hosti i konfiguruar i bisedës, kështu që drejtimi i embedding-eve te një pikë tjetër nuk i jep kurrë asaj pike një pohim delegimi për personin teksti i të cilit po kthehet në embedding.

Produkti i hostuar përdor disa ofrues inference dhe zgjedh mes tyre sipas kostos dhe cilësisë. Një organizatë do të mund të zgjedhë te Admin cilët ofrues mund të përdorin agjentët e saj: vetëm perëndimorë, vetëm evropianë, vetëm kinezë, ose pa preferencë — ofruesi më efikas për çdo punë. Një instancë e vetë-hostuar zgjedh vetë.

Ta ekzekutoni vetë i ndryshon të gjitha këto

Çdo palë e tretë më sipër është zgjedhje konfigurimi në një instancë të vetë-hostuar. Inferenca mund të drejtohet te çdo pikë e pajtueshme me OpenAI, përfshirë një në pajisjet tuaja. Konektorët janë të fikur nëse nuk i ndizni. Hyrja përmes UnlikeOtherAI është rruga e mbështetur, dhe një vendosje pa asnjë ofrues identiteti funksionon si një organizatë e vetme e palidhur me një pronar fillestar.

Kjo është gjithë ideja e kësaj skeme: softueri është i njëjtë, dhe vendimet për vendin ku funksionon dhe çfarë mund të arrijë i përkasin kujtdo që e ekzekuton. Faqja e instalimit shpjegon si.