Bluesky qanday ishlaydi

Bu darsda nima o‘rganasiz

Ijtimoiy tarmoqda 10 yil yozdingiz: minglab post, o‘n minglab obunachi. Bir kuni platforma qoidalarini o‘zgartirdi, tasmangizni boshqa algoritm boshqara boshladi yoki hisobingiz bloklandi. Postlaringizni olib, boshqa joyga ketolmaysiz: obunachilar, havolalar, ism — hammasi platformaniki. Telefon raqamingizni operatordan operatorga olib o‘tish mumkin, ijtimoiy tarmoqdagi hisobingizni esa — yo‘q.

Bluesky shu muammoga muhandislik javobi sifatida tug‘ildi. U 2019-yilda Twitter ichidagi tadqiqot loyihasi sifatida boshlangan, keyin mustaqil kompaniyaga aylangan va 2024-yil fevralda hamma uchun ochilgan. Uning asosi — ochiq protokol, AT Protocol (Authenticated Transfer Protocol). Bluesky ilovasi — shu protokol ustidagi ilovalardan bittasi.

AT Protocol uchta va’da beradi va dars ularning har biri qanday texnik mexanizmga aylanganini ko‘rsatadi:

1. Hisobingiz — sizniki. Postlaringiz imzolangan shaxsiy “repo”da turadi. Uni istalgan serverga ko‘chirish mumkin, va hech kim uni sezdirmasdan o‘zgartira olmaydi. Bu yerda Merkle daraxti, kriptografik imzo va o‘zgarmas identifikator (DID) ishlaydi.

2. Ismingiz — sizniki. Handle — domen: @dinmuhammad.uz. Ismni domen egasi tasdiqlaydi, platforma emas.

3. Algoritm — tanlovingiz. Butun tarmoq bitta ochiq oqim (firehose) sifatida tarqaladi. Har kim o‘z tasmasini (feed) yoki moderatsiya xizmatini yozishi, foydalanuvchi esa ularni tanlashi mumkin.

Har yangi tushuncha avval oddiy tilda, keyin mexanizm sifatida, oxirida raqam bilan beriladi. Dars oxirida — butun darsning o‘n gaplik xulosasi. Oldingi darslardan foydali: Twitter darsidagi tasma qurish (fan-out), Kafka darsidagi jurnal va offset (firehose — xuddi shunday oqim), Amazon S3 darsidagi nazorat summalari va fond birjasi darsidagi “raqamlangan oqim va bo‘shliqni tiklash”.

1. Muammo: platforma sizning hisobingiz egasi

1.1 Markazlashgan tarmoqning uch qulfi

Oddiy tilda: siz ijarada yashaysiz. Kvartira chiroyli, lekin uy egasi qoidalarni o‘zgartirsa, sizni chiqarib yuborsa yoki uyni sotib yuborsa — hech narsa qila olmaysiz. Narsalaringizni ham olib chiqolmaysiz: ular devorga mixlangan.

Markazlashgan ijtimoiy tarmoqda uchta “qulf” bor:

Ma’lumot qulfi. Postlar, obunalar va obunachilar platforma bazasida. Eksport qilish mumkin bo‘lsa ham, boshqa joyga ishlaydigan holda olib o‘tib bo‘lmaydi — obunachilar eski joyda qoladi.

Identifikator qulfi. @ism — platformaning ichki ma’lumoti. Platforma uni olib qo‘yishi yoki boshqaga berishi mumkin. Boshqa joyga ketsangiz — ism qolib ketadi, va unga havolalar buziladi.

Algoritm qulfi. Nimani ko‘rishingizni bitta kompaniya algoritmi hal qiladi. Boshqa tasma xohlasangiz — yagona yo‘l boshqa platformaga ketish (va 1-qulfga qaytish).

1.2 Talablar

To‘rtinchi qator AT Protocol’ni boshqa federativ tarmoqlardan ajratadi (2.3): “like soni”, “javoblar daraxti”, “qidiruv” kabi narsalar butun tarmoq ma’lumotini talab qiladi. Har server faqat o‘zi ko‘rgan qismini bilsa, foydalanuvchi tajribasi markazlashgan tarmoqdan yomonroq bo‘ladi.

1.3 Konvert orqasidagi hisob

Ikkinchi hisob darsning birinchi muhim kuzatuvi: ijtimoiy tarmoqning matnli qismi kichik. Butun tarmoqni bitta joyga yig‘ish (relay) va undan global indeks qurish (AppView) arzon emas, lekin mumkin — va kerak bo‘lsa, buni bir nechta mustaqil tashkilot qila oladi.

2. Nol nuqta: o‘z-o‘zini tasdiqlovchi ma’lumot

2.1 Xesh va imzo oddiy tilda

Oddiy tilda: xesh — hujjatning “barmoq izi”. Hujjatdagi bitta harf o‘zgarsa, barmoq izi butunlay boshqacha bo‘ladi. Imzo — faqat sizda bor kalit bilan qo‘yilgan muhr; uni hamma tekshira oladi (ochiq kalit bilan), lekin hech kim soxtalashtira olmaydi.

Ikkalasini birlashtiring: siz butun hujjatlar to‘plamining barmoq izini olasiz va faqat shu izni imzolaysiz. Endi to‘plam istalgan joyda — sizning serveringizda, do‘stingiz kompyuterida, begona arxivda — turishidan qat’i nazar, kim bo‘lmasin uni tekshira oladi: “bu aynan siz imzolagan to‘plammi?” Ma’lumot o‘z-o‘zini tasdiqlaydi.

yozuvlar:   post-1   post-2   like-7   follow-3   ...
              |        |        |         |
              v        v        v         v
           xesh     xesh     xesh      xesh          (har yozuvning barmoq izi)
              \        |        |        /
               \_______ daraxt (MST) ___/
                          |
                    ildiz xeshi  ----->  commit: {did, rev, ildiz}  + imzo

2.2 Repo — kim saqlashidan qat’i nazar

Bluesky’da har foydalanuvchining hamma ommaviy yozuvlari — postlar, like’lar, repostlar, obunalar, bloklar, profil — bitta repoda. Repo — “kolleksiya/kalit → yozuv” lug‘ati:

app.bsky.actor.profile/self           -> {"displayName": "Dinmuhammad", ...}
app.bsky.feed.post/3l2xq6...          -> {"text": "Salom!", "createdAt": "..."}
app.bsky.feed.like/3l2xr1...          -> {"subject": {"uri": "at://did:plc:abc/app.bsky.feed.post/3k9..."}}
app.bsky.graph.follow/3l2xs8...       -> {"subject": "did:plc:xyz"}

E’tibor bering: like va follow — ham sizning repo’ngizdagi yozuvlar. “A B ning postini yoqtirdi” degan fakt A ning repo’sida turadi va A ning imzosi bilan. B ning serveri bu haqda bilmasligi ham mumkin. Postga nechta like borligini bilish uchun butun tarmoqni ko‘rish kerak — bu AppView vazifasi (9-qadam).

Har yozuvning manzili — AT URI: at://<did>/<kolleksiya>/<kalit>. Unda server manzili yo‘q — faqat hisob identifikatori (DID). Hisob boshqa serverga ko‘chsa ham, URI o‘zgarmaydi.

2.3 Ikki xil federatsiya

“Markazlashmagan ijtimoiy tarmoq” deganda ko‘pincha Mastodon (ActivityPub protokoli) tushuniladi. U boshqa yo‘l tutgan:

ActivityPub (Mastodon):
  server = jamoa. Hisob serverga bog'langan: @ali@server-a.uz
  server A postni o'z obunachilari turgan serverlarga YUBORADI (push)
  har server faqat o'z foydalanuvchilari va ular kuzatganlarni biladi
  -> "kichik dunyolar": like soni va javoblar har serverda boshqacha

AT Protocol (Bluesky):
  qatlamlar: ma'lumot (PDS) | yig'ish (relay) | ko'rinish (AppView) | tanlov (feed'lar)
  hisob DID ga bog'langan, server istalgan vaqtda almashadi
  hamma narsa bitta ochiq oqimga yig'iladi -> "katta dunyo": global ko'rinish

Ikkalasi ham markazlashmagan, lekin markazlashmaslik turli qatlamda. Mastodon’da jamoalar (serverlar) mustaqil, va har biri o‘z qoidalariga ega. AT Protocol’da esa ma’lumot va identifikator foydalanuvchiga tegishli, “ko‘rinish” qatlami (AppView) esa katta va qimmat, lekin almashtiriladigan. Farqlar va har birining narxi — 16-bo‘limda.

2.4 To‘rt rol bitta rasmda

Darsning qolgan qismida to‘rtta so‘z doim uchraydi. Ularni bitta rasm bilan eslab qolish oson — shahar kutubxonalari tarmog‘i:

PDS — sizning shaxsiy javoningiz, qaysidir kutubxonada ijaraga olingan. Unda faqat sizning daftarlaringiz, sizning imzongiz bilan. Javonni boshqa kutubxonaga ko‘chirish mumkin.

Relay — pochta markazi: har kutubxonadan “bugun qaysi daftarlarga qanday sahifa qo‘shildi” degan xabarlarni yig‘ib, bitta umumiy tasmaga tizadi va kim so‘rasa, o‘shanga beradi. U daftarlarni o‘zgartira olmaydi — imzolar buni darhol ko‘rsatadi.

AppView — katalog bo‘limi: pochta markazidan kelgan hamma xabarni o‘qib, “qaysi kitob haqida kim nima yozgan”, “kim kimga obuna” degan kartotekani yuritadi. Siz “menga yangiliklarni ko‘rsat” desangiz — katalog bo‘limi javob beradi.

Feed generator — tavsiya qiluvchi kutubxonachi: katalogdan o‘z didiga ko‘ra ro‘yxat tuzadi (“bu hafta eng qiziq ilmiy maqolalar”). Siz istalgan kutubxonachining ro‘yxatini tanlaysiz va istalgan vaqtda boshqasiga o‘tasiz.

Asosiy farq markazlashgan tarmoqdan: bu yerda to‘rtala rolni turli tashkilotlar bajarishi mumkin, va ular orasidagi aloqa ochiq qoidalar bilan. Javon (ma’lumot) va ism (DID) — sizniki; qolganlari — xizmatlar, ularni almashtirish mumkin.

3. v0: bitta server, bitta baza

Eng sodda mikroblog — bitta serverda uchta jadval. Twitter darsidagi boshlang‘ich nuqta bilan deyarli bir xil:

import time

class Microblog:
    def __init__(self):
        self.users = {}        # ism -> {"parol_xeshi": ..., "yaratildi": ...}
        self.posts = []        # (id, muallif, matn, vaqt)
        self.follows = set()   # (kim, kimni)
        self.likes = set()     # (kim, post_id)

    def post(self, author, text):
        pid = len(self.posts)
        self.posts.append((pid, author, text, time.time()))
        return pid

    def follow(self, who, whom):
        self.follows.add((who, whom))

    def like(self, who, pid):
        self.likes.add((who, pid))

    def timeline(self, viewer, limit=50):
        following = {b for a, b in self.follows if a == viewer} | {viewer}
        mine = [p for p in self.posts if p[1] in following]
        return sorted(mine, key=lambda p: p[3], reverse=True)[:limit]

Bu v0 ishlaydi va hatto katta bo‘lishi mumkin: Twitter darsida ko‘rganimizdek, kesh, fan-out va shardlar bilan bunday tizim yuz millionlab foydalanuvchiga xizmat qiladi. Lekin bu darsning savoli boshqa: tezlik emas, egalik. Va bu yerda v0 birinchi kundanoq “sinib” tug‘ilgan.

Darsning oxirigacha v0 dagi har jadval qayerga “ko‘chishini” ko‘ramiz:

Ko‘rinib turibdiki, v0 ning ma’lumot qismi foydalanuvchilarga taqsimlanadi, hisoblash qismi (tasma, sonlar) esa xizmatlarga.

4. Nima sindi

v0 ga 1-bo‘limdagi talablarni qo‘yamiz. Tezlik muammolari Twitter darsida hal qilingan; bu yerda — egalik, ishonch va tanlov muammolari. Har muammo 5-bo‘limdagi bir yoki bir nechta qadamga olib keladi.

4.1 Hisob serverga mixlangan

v0 da users jadvali — server bazasida. Server yopilsa yoki sizni chiqarsa — hisob yo‘q. Boshqa server ochilsa ham, u sizning postlaringiz aynan sizniki ekanini tekshira olmaydi: eksport faylini istalgancha tahrirlash mumkin. Kerak: ma’lumot o‘z-o‘zini tasdiqlasin (2–4-qadamlar).

4.2 Ism — serverniki

Ism users jadvalining kaliti. Server uni boshqaga berishi yoki olib qo‘yishi mumkin. Agar @ali ismini o‘zgartirsa, unga barcha havolalar (javoblar, iqtiboslar) buziladi — chunki ular ismga ishora qiladi. Kerak: o‘zgarmas ichki identifikator va o‘zgaruvchan, lekin tasdiqlanadigan ko‘rinadigan ism (5–6-qadamlar).

4.3 Bitta algoritm, bitta moderator

timeline — bitta funksiya. Boshqa tasma kerak bo‘lsa — boshqa platforma. Moderatsiya ham shunday: nimani yashirish, nimani belgilash — bitta kompaniya qarori. Kerak: tasma va moderatsiya — tashqi, almashtiriladigan xizmatlar (10–11-qadamlar).

4.4 Ko‘p server — kimga ishonish

v0 ni ko‘p serverga bo‘lsak (har kim o‘z serverida), yangi muammo paydo bo‘ladi: server A “Ali shu postni yozdi” desa, server B bunga nega ishonishi kerak? Server A yolg‘on gapirishi, buzilishi yoki eski ma’lumot berishi mumkin. Kerak: ishonch serverga emas, imzoga (2-qadam).

4.5 Hamma hamma bilan gaplashadi

Ko‘p serverli v0 da like sonini bilish uchun har server boshqa hammasidan so‘rashi kerak (1.3 dagi N × N). Tasma qurish uchun — obunalaringiz turgan har serverdan. Sekin, qimmat va bitta sekin server hammani sekinlashtiradi. Kerak: yig‘uvchi qatlam (relay) va global indeks (AppView) — 8–9-qadamlar.

4.6 Ko‘chish — havolalar buziladi

Hisob server A dan B ga ko‘chsa, boshqa serverlardagi “Ali A da” degan ma’lumot eskiradi: javoblar, obunalar, iqtiboslar A ga ishora qiladi. Kerak: boshqalar sizni joylashuv emas, identifikator orqali topsin, identifikator esa joriy joylashuvni aytsin (5, 12-qadamlar).

Bitta aniq misol bilan: Ali v0 serveridan boshqa ko‘p serverli tizimga o‘tmoqchi. U postlarini eksport qiladi (JSON fayl) va yangi serverda import qiladi. Natija: (1) yangi serverda Ali — yangi hisob, ali@yangi-server; eski obunachilar uni ko‘rmaydi; (2) eski postlarga qoldirilgan 3 000 ta javob eski serverda qoladi va endi “hech kimga” tegishli; (3) Valining “Ali postini iqtibos qildi” degan posti eski manzilga ishora qiladi — havola o‘ladi; (4) yangi server import qilingan postlarni “haqiqatan Ali yozganmi” deb tekshira olmaydi. To‘rtala muammoning ildizi bitta: hisob va ma’lumot serverga bog‘langan, o‘z-o‘zini tasdiqlamaydi.

4.7 Muammolar ro‘yxati

5. Evolyutsiya: o‘n to‘rt qadam

Qadamlar mantiqiy tartibda: 1–4 — ma’lumot o‘z-o‘zini tasdiqlashi, 5–7 — identifikator va uy, 8–9 — butun tarmoqni yig‘ish va ko‘rsatish, 10–11 — tanlov, 12–14 — chiqib ketish va ekotizim.

kalit                          xesh boshi (bit)      daraja
app.bsky.feed.like/3l2a...     0001 0110 ...          1   (3 ta nol -> 1)
app.bsky.feed.post/3k9z...     1011 0001 ...          0
app.bsky.feed.post/3l1b...     0000 0011 ...          3   (6 ta nol -> 3)
app.bsky.graph.follow/3jx...   0100 1110 ...          0

Qoida: to'plamning eng yuqori darajadagi kalitlari — ildiz tugunida.
Ular orasidagi kalitlar — pastki daraxtlar, ular ham shu qoida bilan.

op 0 (genezis): rotatsiya kalitlari [R1 (foydalanuvchi), R2 (PDS)],
                imzo kaliti S1, handle, PDS manzili         — R1 yoki R2 imzosi
op 1:           PDS manzili o'zgardi (ko'chish)              — R2 imzosi
op 2:           imzo kaliti S1 -> S2                          — R2 imzosi
...
did = "did:plc:" + base32(sha256(op 0)) dan 24 belgi

1. handle -> DID:   DNS TXT yozuvi  _atproto.dinmuhammad.uz  "did=did:plc:abc..."
                    yoki HTTPS:     https://dinmuhammad.uz/.well-known/atproto-did
2. DID -> handle:   DID hujjatida   alsoKnownAs: ["at://dinmuhammad.uz"]
ikkalasi mos -> handle tasdiqlangan

Relay QILA OLMAYDI:
  - post yoki like'ni soxtalashtirish  (imzo - 2-qadam)
  - repo mazmunini sezdirmasdan o'zgartirish (MST ildizi imzo ostida)

Relay QILA OLADI:
  - ba'zi hisoblar hodisalarini yashirish yoki kechiktirish
  - oqimni to'xtatish
  - tartibni o'zgartirish (turli repo'lar orasida)

Himoya:
  - bir nechta mustaqil relay (hamma o'z relay'ini yurita oladi)
  - iste'molchi shubha qilsa, to'g'ridan-to'g'ri PDS dan butun repo'ni
    so'raydi (resinxronizatsiya) va o'zi tekshiradi
  - repo versiyalari zanjiri (rev, since): bo'shliq ko'rinadi

kirish:  at://did:plc:ali/app.bsky.feed.post/3l2x...
chiqish: {
  muallif:  {did, handle: "ali.uz", ism: "Ali", avatar: CDN havola},
  matn:     "Salom, dunyo!",  rasmlar: [CDN havolalar],
  sonlar:   {like: 120, repost: 8, javob: 14},
  ko'ruvchi: {like_bosganmi: true, repost_qilganmi: false},
  yorliqlar: ["..."],     <- obuna bo'lingan yorliqlovchilardan
  ko'rinadimi: blok va mute hisobga olingan
}

ilova -> AppView: "feed X ni ber, kursor = ..."
AppView -> feed generator X: getFeedSkeleton(ko'ruvchi, limit, kursor)
feed X -> AppView: [at://.../post/1, at://.../post/2, ...] + yangi kursor
AppView: bloklar va moderatsiya bo'yicha filtrlaydi, to'ldiradi -> ilovaga

1. Yangi PDS da hisob ochish (xuddi shu DID bilan, hali faol emas)
2. Repo'ni ko'chirish: eski PDS dan CAR eksport -> yangi PDS ga import
3. Bloblarni ko'chirish (rasmlar, video)
4. Shaxsiy sozlamalarni ko'chirish (mute, feed tanlovlari)
5. DID hujjatini yangilash: yangi PDS manzili va yangi imzo kaliti
   (PLC operatsiyasi, rotatsiya kaliti bilan imzolangan)
6. Yangi PDS da hisobni faollashtirish, eskisida o'chirish
   -> firehose: #identity, #account; relay va AppView yangi PDS dan o'qiydi

6. Bitta postning hayoti

6.1 Qadam-baqadam

Ali telefonda “Salom, dunyo!” deb yozib, “Post” tugmasini bosdi. Uning obunachisi Vali shu postni tasmasida ko‘radi va like bosadi:

1. Ilova Ali’ning PDS iga createRecord yuboradi: kolleksiya app.bsky.feed.post, yozuv (matn, vaqt, til).
2. PDS yozuvni Lexicon bo‘yicha tekshiradi, TID kalit beradi, MST ga qo‘shadi, yangi ildiz bilan commit yaratadi va imzolaydi, o‘z firehose’iga e’lon qiladi.
3. Relay hodisani oladi, imzoni DID hujjatidagi kalit bilan tekshiradi, o‘z oqimiga o‘z seq raqami bilan qo‘shadi.
4. AppView hodisani indekslaydi: yangi post, muallif, vaqt; obunachilar tasmalariga kirishi mumkin.
5. Vali tasmasini ochadi — ilova AppView’dan so‘raydi, post ko‘rinadi.
6. Vali like bosadi: ilova Valining PDS iga app.bsky.feed.like yozuvini yaratadi; u ham relay orqali AppView’ga keladi, va AppView post like sonini oshiradi va Ali’ga bildirishnoma tayyorlaydi.

6.2 O‘qish va yozish turli joylarda

AT Protocol’ning asosiy arxitektura xususiyati: yozish — muallifning PDS iga (manba haqiqati), o‘qish — AppView’dan (hosila ko‘rinish). Bu ma’lumotlar bazalaridagi CQRS naqshiga o‘xshaydi: yozish modeli va o‘qish modeli alohida, ular orasida — jurnal (firehose). Kafka darsidagi “jurnal — haqiqat, jadval — hosila” tamoyili, faqat bu yerda jurnal minglab mustaqil PDS lardan yig‘iladi.

Natija — o‘z yozuvingizni o‘qish muammosi: Ali post yozdi va darhol profilini yangiladi; AppView hali indekslamagan bo‘lsa, post ko‘rinmaydi. Yechim: ilova (yoki PDS) foydalanuvchining o‘z so‘nggi yozuvlarini AppView javobiga qo‘shib beradi — yozuvchi o‘z o‘zgarishlarini darhol ko‘radi, boshqalar esa bir oz keyin.

6.3 O‘chirish va tahrir qanday tarqaladi

Ali postini o‘chirdi. PDS repo’dan yozuvni olib tashlaydi, MST ni yangilaydi va yangi commit chiqaradi: firehose’da delete amali — faqat yo‘l (app.bsky.feed.post/3l2x...), yozuvning o‘zi yo‘q. AppView postni indeksdan olib tashlaydi, tasmalardan va qidiruvdan yo‘qotadi.

Lekin boshqalarning yozuvlari qoladi: Valining like’i, Salimning javobi va iqtibosi — ularning repo’larida, va ular o‘chirilgan postga ishora qiladi. AppView ularni “o‘chirilgan postga javob” deb ko‘rsatadi. Bu dizaynning tabiiy natijasi: Ali faqat o‘z repo’sini boshqaradi, boshqalarning yozuvlarini — yo‘q. Amaliyotdagi like hisobi ham shuni aks ettiradi: post o‘chsa ham, unga qilingan like yozuvlari sanaladi (ular hali bor).

Tahrir protokol darajasida mumkin — update amali: yozuv o‘zgaradi, yangi commit, firehose’da yangi qiymat. Bluesky ilovasi esa uzoq vaqt postlarni tahrirlashni ko‘rsatmagan: javoblar va iqtiboslar asl matnga yozilgan, va tahrir ularning ma’nosini o‘zgartirishi mumkin. Bu protokol cheklovi emas — ilova va jamiyat qarori. Profil, ro‘yxatlar va boshqa yozuvlar esa bemalol yangilanadi.

7. Identifikatsiya: handle’dan kalitgacha

7.1 Kim bu?

Ilova @dinmuhammad.uz ni ko‘rsatishdan oldin yoki uning postini tekshirishdan oldin, uchta savolga javob kerak: bu handle qaysi DID ga tegishli, bu DID ning joriy imzo kaliti qaysi, va repo qaysi PDS da.

7.2 Kalit almashtirilganda

Imzo kaliti almashtirildi (masalan, PDS kalitni yangiladi yoki hisob ko‘chdi). Firehose’da #identity hodisasi chiqadi. Iste’molchi o‘z keshidagi kalitni tashlab, DID hujjatini qayta o‘qishi kerak — aks holda yangi kalit bilan imzolangan commitlar “soxta” ko‘rinadi va tashlanadi. Amaliyotdagi AppView aynan shuni qiladi: Identity hodisasida keshni tozalaydi.

                 odam uchun        mashina uchun
o'qiladi          ha                yo'q
o'zgaradi         ha (domen)        yo'q
noyob             DNS kafolati      xesh kafolati
tekshiriladi      DNS orqali        imzolangan jurnal (PLC)
havolalarda       YO'Q (ko'rsatish) HA (at://did/...)

7.3 did:web yoki did:plc

Ikki DID turi ikki xil murosa:

did:web — did:web:dinmuhammad.uz. DID hujjati domendagi faylda turadi. Hech qanday katalog kerak emas, to‘liq mustaqil. Lekin DID domenning o‘zi: domenni yo‘qotsangiz (muddati tugadi, sotildi, buzildi) — butun identifikatorni yo‘qotasiz, va uni boshqa domenga ko‘chirib bo‘lmaydi. Kalit almashtirish tarixi ham yo‘q: hujjat shunchaki o‘zgaradi.

did:plc — katalog orqali, lekin domendan mustaqil: handle’ni istalgancha almashtirish mumkin, DID o‘zgarmaydi. Hujjat tarixi imzolangan va tekshiriladi, ustuvor rotatsiya kaliti bilan tiklash mumkin. Narxi — katalogga bog‘liqlik.

Ko‘pchilik foydalanuvchi uchun did:plc amaliyroq: domen ixtiyoriy, hisob xavfsizroq. did:web esa o‘z domenini o‘nlab yillar boshqaradigan tashkilotlar uchun mantiqli. Muhim: tanlov hisob yaratilganda qilinadi va keyin o‘zgarmaydi — chunki DID ning o‘zi o‘zgarmaydi.

8. Sinxronizatsiya va ishonch

8.1 Bo‘shliqni sezish va tiklash

Firehose ishonchsiz tarqatuvchidan keladi: hodisalar yo‘qolishi, takrorlanishi, kechikishi mumkin. Iste’molchi har repo uchun oxirgi qo‘llangan versiyani (rev) eslab qoladi va har yangi commitning since (oldingi versiya) maydonini tekshiradi:

Uch qoida (amaliyotdagi appview.py):

1. since == oxirgi versiya → qo‘llash.
2. rev ≤ oxirgi versiya → eski yoki takror, tashlash.
3. Aks holda — bo‘shliq: butun repo so‘raladi, shu repo’ning keyingi commitlari buferga, surat kelgach — suratdan yangilari qo‘llanadi.

Bundan tashqari, butun oqim uchun kursor (oxirgi seq): uzilishdan keyin relay’ga “shu seq dan keyingilarni ber” deyiladi. Relay o‘z tarixini cheklangan muddat (masalan, bir necha kun) saqlaydi; undan uzoq uzilishda — to‘liq qayta to‘ldirish (backfill): har repo’ni alohida yuklab olish.

8.2 Kimga ishonamiz

Qatlam            Nimani kafolatlaydi               Nimani kafolatlamaydi
PDS (yozish)      yozuv egasining kaliti bilan      PDS kalitni boshqaradi —
                  imzolangan                        foydalanuvchi PDS ga ishonadi
DID / PLC         kalit va manzil tarixi imzolangan katalog operatsiyani yashirishi mumkin
Relay             tartibli, imzolari tekshirilgan   to'liqlik: hodisani yashirishi,
                  oqim                              kechiktirishi mumkin
AppView           butun tarmoq ko'rinishi           sonlar va tasmalar — AppView
                                                    hisoblagani; tekshirib bo'lmaydi
Feed generator    tanlov                            nimani tanlaganini tushuntirmaydi

8.3 Ikki xil tartib: seq va rev

Amaliyotdagi AppView ikkita “raqam” bilan ishlaydi va ularni adashtirish — eng ko‘p uchraydigan xato:

seq — relay oqimidagi tartib raqami (butun tarmoq uchun bitta)
      vazifasi: "qayerdan davom etaman" (kursor), takrorlarni tashlash
      relay almashsa — seq ham boshqacha (har relay o'z raqamlari)

rev — bitta repo versiyasi (shu foydalanuvchi uchun)
      vazifasi: "bu commit mening oxirgi ko'rganimdan keyingisimi"
      PDS beradi, imzo ostida — relay o'zgartira olmaydi

seq — tarqatish tartibi, rev — mazmun tartibi. Relay boshqa relay bilan almashtirilsa, kursor (seq) noldan boshlanadi, lekin har repo’ning rev i o‘sha — AppView qaysi commitlar yangi ekanini baribir biladi. Va aksincha: seq bo‘yicha takrorni tashlash oson, lekin u “bu repo’dan biror commit yo‘qolganmi” degan savolga javob bermaydi — buni faqat rev zanjiri (since) ko‘rsatadi. Shuning uchun amaliyotda ikkala tekshiruv ham bor: kursor bo‘yicha dedup va rev/prev bo‘yicha bo‘shliq. Fond birjasi darsida ikkalasi bitta raqam edi (bitta oqim, bitta manba); bu yerda manbalar ko‘p — raqamlar ham ikkita.

9. Bugungi arxitektura

Rasmning asosiy g‘oyasi — qatlamlarni ajratish. Markazlashgan tarmoqda bu besh qatlam bitta kompaniyaning bitta tizimi. AT Protocol’da har qatlam ochiq interfeys bilan ajratilgan va almashtirilishi mumkin: ma’lumot qatlami (PDS) arzon va ko‘p, yig‘ish va ko‘rinish qatlamlari (relay, AppView) qimmat va kam — lekin almashtiriladigan.

Twitter darsidagi arxitektura bilan solishtirish foydali — vazifalar o‘sha, faqat tashkilotlar orasida bo‘lingan:

Texnik jihatdan AT Protocol “ichki xabarlar navbati”ni ommaviy qildi: kompaniya ichidagi Kafka oqimi o‘rniga — hamma o‘qiy oladigan firehose. Shu bitta qaror global ko‘rinish, maxsus feed’lar va mustaqil ilovalarni mumkin qiladi — va maxfiylik bilan bog‘liq yangi savollarni tug‘diradi.

10. Ishonchlilik

10.1 Nosozliklar taksonomiyasi

Muhim xususiyat — qisman ishlash. Markazlashgan tarmoqda baza to‘xtasa — hamma narsa to‘xtaydi. AT Protocol’da qatlamlar ajratilgan: AppView orqada qolsa ham foydalanuvchilar yozishda davom etadi (yozuvlar PDS da xavfsiz), AppView keyin yetib oladi — Kafka darsidagi “lag” kabi.

10.2 O‘sish to‘lqinlari

Bluesky’ning eng og‘ir sinovlari — texnik nosozliklar emas, keskin o‘sish to‘lqinlari: boshqa platformadagi voqealar tufayli bir necha kun ichida millionlab yangi foydalanuvchi.

11. Xavfsizlik va spam

11.1 Kalitlar va hisob o‘g‘irlanishi

Ikki xil kalit — ikki xil xavf (5-qadam). Imzo kaliti PDS da: u o‘g‘irlansa, hujumchi hisob nomidan post yozadi, lekin DID ni o‘zgartira olmaydi. Rotatsiya kaliti — DID egaligi: kim uni boshqarsa, hisobni boshqa joyga olib keta oladi. Shuning uchun ehtiyotkor foydalanuvchi o‘ziga tegishli, oflayn saqlanadigan ustuvor rotatsiya kalitini qo‘shadi: PDS buzilib, DID boshqa joyga ko‘chirilsa ham, 72 soat ichida bekor qilish mumkin.

Ilovalar uchun esa oddiy tajriba: parol va ikki faktorli autentifikatsiya, uchinchi tomon ilovalari uchun ilova parollari yoki OAuth — asosiy parolni bermasdan, cheklangan huquqli kirish.

11.2 Ochiq tarmoqda spam

Ochiq tarmoqda hisob yaratish arzon, firehose esa hammaga ochiq — spam uchun ideal muhit. Himoya qatlamlari: hisob yaratishda tekshiruvlar (PDS darajasida), PDS va relay darajasida tezlik chegaralari (bir hisobdan sekundiga N ta yozuv), relay’ning yangi va noma’lum PDS larga ehtiyotkorligi (dastlab hisoblar soni va yozish tezligiga cheklov), AppView va yorliqlovchilarning avtomatik tasniflagichlari.

12. Iqtisod: kim to‘laydi

12.1 Qatlamlar narxi

Markazlashmagan tarmoqda savol: qimmat qatlamlarni kim yuritadi va nega?

Qatlam       Yuritish narxi    Kim yuritadi (amalda)       Almashtirish narxi
PDS          juda past         Bluesky + minglab mustaqil   past: hisob ko'chadi
Relay        o'rtacha          bir nechta                  o'rtacha
AppView      yuqori            asosan Bluesky; bir nechta   yuqori: indeks noldan
                               ixtisoslashgan              (lekin ma'lumot ochiq)
Feed         past-o'rtacha     minglab                     juda past: bitta bosish

13. Sig‘im rejalashtirish

13.1 Firehose va indeks o‘sishi

13.2 Tasma: qachon quriladi

“Following” tasmasini qurishning ikki yo‘li Twitter darsida batafsil ko‘rilgan: yozishda tarqatish (har post obunachilarning tayyor tasmalariga yoziladi) va o‘qishda yig‘ish (so‘rov paytida kuzatilganlar postlari birlashtiriladi). Amaliyotdagi AppView ikkinchisini ishlatadi: har muallif postlari tartiblangan ro‘yxatda, so‘rovda — heapq.merge.

Yozishda tarqatish:
  + o'qish juda tez (tayyor ro'yxat)
  - har post x obunachilar soni yozuv: mashhur hisob (1 M obunachi) —
    bitta post = 1 M yozuv -> to'lqinda indekslash orqada qoladi
  - follow/unfollow, blok, hisob o'chirilishi — tayyor tasmalarni tuzatish
  - AppView ni noldan qayta qurish — juda qimmat

O'qishda yig'ish:
  + yozish arzon: post — bitta yozuv
  + blok, o'chirish, moderatsiya — so'rov paytida qo'llanadi
  - o'qishda N ta ro'yxatni birlashtirish (kuzatilganlar soni)
  - 5 000 kishini kuzatadigan foydalanuvchi — og'ir so'rov

13.3 Qayerda cheklov

Har qatlamning o‘z chegarasi bor, va ular turlicha o‘sadi: PDS — hisoblar soni va bloblar hajmi bilan (arzon, gorizontal: yangi PDS qo‘shiladi); relay — butun tarmoq commitlari va iste’molchilar soni bilan (asosan tarmoq trafigi); AppView — butun tarmoq yozuvlari (indeks, faqat o‘sadi) va o‘quvchilar soni (so‘rovlar) bilan. Eng tez o‘sadigani — AppView o‘qish yuki: har yangi faol foydalanuvchi kuniga yuzlab so‘rov qiladi, ko‘pi tasma va bildirishnomalar. Shuning uchun AppView’da keshlar (Twitter darsi) va “to‘ldirish” qatlamini optimallash eng katta tejash beradi; PDS va relay esa ko‘pincha tarmoq va disk narxi bilan cheklanadi.

14. Kuzatuv

14.1 Nima o‘lchanadi

14.2 Uchidan-uchiga tekshiruv

Ichki metrikalar har qatlamni alohida ko‘rsatadi; foydalanuvchi esa butun zanjirni ko‘radi. Shuning uchun sintetik hisob: maxsus hisob har daqiqada post yozadi (o‘z PDS iga) va o‘lchanadi: (1) PDS javob vaqti; (2) post relay oqimida qachon paydo bo‘ldi; (3) AppView’da qachon ko‘rinadigan bo‘ldi (boshqa sintetik hisobning tasmasidan so‘rab); (4) feed generator va qidiruvda qachon. Har bosqich uchun gistogramma — “yozilgandan ko‘rinadigan”gacha bo‘lgan haqiqiy vaqt. Xuddi shunday sintetik like va follow: hisoblagich bir necha soniyada o‘zgarishi kerak.

15. Antinaqshlar

16. Trade-off‘lar

Butun dars o‘nta gapda

1. Muammo — egalik, tezlik emas: ma’lumot, ism va algoritm platformaga mixlangan; ko‘chish — hammasini yo‘qotish (1-bo‘lim).
2. Ma’lumot o‘z-o‘zini tasdiqlaydi: yozuvlar xeshlanadi, daraxtga joylanadi, ildiz imzolanadi — kim saqlashidan qat’i nazar (2-bo‘lim, 2-qadam).
3. MST — butun repo bitta xeshda: shakli kalitlarning o‘zidan; isbot va farq — faqat yo‘ldagi tugunlar (3-qadam).
4. Har harakat — harakat qiluvchining yozuvi: like va follow sizning repo’ngizda; sonlar — butun tarmoqni ko‘ruvchida (2.2, 6-bo‘lim).
5. DID — o‘zgarmas ID, handle — domen: havolalar DID ga; ism ikki tomonlama tekshiriladi; rotatsiya kaliti — hisob egaligi (5–6-qadamlar).
6. Yozish — PDS ga, o‘qish — AppView’dan: manba va hosila ajratilgan, orasida — firehose (6.2, 7–9-qadamlar).
7. Relay — ishonchsiz tarqatuvchi: soxtalashtira olmaydi, faqat yashira oladi; bo‘shliq rev zanjiri bilan ko‘rinadi (8-bo‘lim).
8. Firehose iste’molchisi — holat saqlovchi: imzo, takror, bo‘shliq, resinxronizatsiya; hodisa — buyruq emas, holat haqida xabar (8, 15-bo‘limlar).
9. Tanlov — qatlamlar orqali: feed’lar va yorliqlovchilar almashtiriladi, AppView baribir filtrlaydi (10–11-qadamlar).
10. Kafolat — chiqish narxi past: qimmat qatlamlar kam joyda, lekin ma’lumot ochiq va ko‘chiriladi — raqobat imkoniyati bozorni ushlaydi (12, 16-bo‘limlar).

17. Intervyu savollari

17.1 Ma’lumot va identifikator

17.2 Oqim, indeks va ishonch

17.3 Masshtab, iqtisod va dizayn

18. Amaliyot

To‘rt daraja. Ikkinchi daraja uchun kod docs/amaliyot/bluesky/ da: repo.py — soddalashtirilgan Merkle Search Tree, to‘rtta funksiya TODO; appview.py — firehose indeksi, oltita joy TODO; model.py — tayyor xesh, kalit darajasi, o‘quv imzosi va hodisa turlari; sim.py — foydalanuvchilar, PDS lar va “yomon” relay simulyatori; check.py — 19 ta tekshiruv, taxminan 5 soniya. Faqat Python standart kutubxonasi.

Ochiq parametrlar: tub P = 2Q + 1, generator G (Q tartibli guruh)
Maxfiy kalit: x (tasodifiy son),  ochiq kalit: Y = G^x mod P

Imzolash (xabar m):
  k = xesh(x, m)           # har xabar uchun bir martalik son (deterministik)
  R = G^k mod P
  e = xesh(R, m) mod Q
  s = (k + x * e) mod Q    -> imzo: (R, s)

Tekshirish:   G^s == R * Y^e  (mod P) ?
  chunki G^s = G^(k + x e) = G^k * (G^x)^e = R * Y^e

har qadamda:
  tasodifiy foydalanuvchi: post / tahrir / o'chirish / like / follow (1-3 amal)
  ba'zan: kalit almashtirish (#identity), hisobni o'chirish/qaytarish (#account),
          soxta commit (begona kalit bilan)
tarmoq: commitlarning 3% i yo'qoladi, 3% i takrorlanadi, qo'shnilar o'rni almashadi
resinxronizatsiya: so'ralgan repo 1-25 qadamdan keyin yetkaziladi
oxirida: har PDS joriy kalit bilan bo'sh commit yuboradi (bo'shliqlar ochiladi)
tekshiruv: like_count, follower_count, timeline — haqiqat bilan AYNAN

ikki stek, har biri kalitlar tartibida aylanadi:
  navbatdagi element: ("daraxt", tugun) yoki ("yozuv", kalit, qiymat)

ikkalasi ham daraxt va xeshlari teng   -> ikkalasini ochmasdan tashla
bir tomonda daraxt                     -> o'sha daraxtni och (bolalari stekka)
ikkalasi ham yozuv:
  kalitlar teng   -> qiymat farqli bo'lsa: o'zgargan
  chapdagi kichik -> o'chirilgan; o'ngdagi kichik -> qo'shilgan

19. Lug‘at

20. Raqamlar manbasi

Faol foydalanuvchilar ulushi, kunlik yozuvlar va ularning taqsimoti, yozuv va commit hajmlari, firehose va relay trafigi, PDS, relay va AppView narxlari, indeks hajmlari, moderatsiya yuklamasi, to‘lqin paytidagi raqamlar — illyustratsiya uchun taxminiy. Bluesky infratuzilmasining ichki raqamlari to‘liq ochiq emas va tez o‘zgaradi; darsdagi mexanizmlar ochiq spetsifikatsiyalar, ochiq kod, muhandislar yozgan maqola va blog postlariga asoslangan. Asosiy xulosalar — o‘z-o‘zini tasdiqlovchi repo, DID va handle ajratilishi, yozish va o‘qishning firehose orqali ajratilishi, PDS arzon va AppView qimmat ekanligi — bu raqamlarning bir necha barobarlik xatosiga ham chidamli.

21. Manbalar

• AT Protocol spetsifikatsiyalari (atproto.com): Data Model, Lexicon, Repository, DID, Handle, Event Stream (Sync), XRPC
• Martin Kleppmann, Paul Frazee, Jake Gold, Jay Graber va boshq. (2024), “Bluesky and the AT Protocol: Usable Decentralized Social Media”, ACM CoNEXT workshop (arXiv:2402.03239)
• did:plc spetsifikatsiyasi (bluesky-social/did-method-plc)
• Alex Auvolat, François Taïani (2019), “Merkle Search Trees: Efficient State-Based CRDTs in Open Networks”, SRDS
• W3C (2022), “Decentralized Identifiers (DIDs) v1.0”
• W3C (2018), “ActivityPub”
• Bluesky blogi: federatsiya arxitekturasi (2023), maxsus feed’lar (2023), “stackable” moderatsiya va Ozone (2024), Jetstream (2024)
• Claus-Peter Schnorr (1991), “Efficient Signature Generation by Smart Cards”, Journal of Cryptology
• Ralph Merkle (1987), “A Digital Signature Based on a Conventional Encryption Function”, CRYPTO (Merkle daraxtlari)