في 6 أكتوبر، قام Telegram بتحديث Serverless، وهي منصته الخاصة بكود البوتات. أصبحت الآن تستضيف الواجهة الأمامية للتطبيقات المصغرة أيضاً: يتم رفع البنية (build) مع البوت بأمر واحد وتُفتح على عنوان من النوع app<id>.tgcloud.ai. أصبحت للتطبيق المصغر وظائف خادمية يستدعيها من telegram-web-app.js. يؤثر هذا التحديث على كل من يستضيف الواجهة الخلفية للبوت أو التطبيق المصغر على خادمه الخاص، وعلى أولئك الذين نقلوا البوت الخاص بهم إلى Serverless في يوليو: يجب نقل المشروع القديم مرة واحدة إلى تخطيط المجلدات الجديد.

قسم التغييرات الأخيرة في وثائق Telegram Serverless بتاريخ 6 أكتوبر 2026

Serverless هو واجهة خلفية للبوتات يشغلها Telegram على خوادمه الخاصة. يُكتب الكود كوحدات JavaScript عادية ويُنفذ في معزلات V8 (V8 isolates)، أي في بيئات معزولة خفيفة داخل عملية واحدة، بجانب Bot API. يرفق بالكود قاعدة بيانات SQLite ووصول HTTP خارجي. لا حاجة لخوادم أو حاويات أو webhooks خاصة بك. صدر الإصدار الأول من أداة سطر الأوامر @tgcloud/cli على npm في 12 يوليو، وظهرت صفحة التوثيق في أرشيف الويب في 13 يوليو. في ذلك الوقت، كانت المنصة قادرة فقط على الاستجابة لتحديثات البوت: لم يكن هناك قسم للواجهة الأمامية في وثائق يوليو، ولا كلمة "endpoint".

ماذا تغير في 6 أكتوبر

ماذاكيف يعمل
استضافة التطبيق المصغريتم رفع مجلد البنية (dist في Vite) مع كود البوت ويُقدم من https://app<app_id>.tgcloud.ai/
النقاط الطرفية (Endpoints)يصبح الملف tgcloud/endpoints/<name>.js دالة يستدعيها التطبيق المصغر بالاسم
الأداة 0.2.0نُشرت على npm في 6 أكتوبر الساعة 10:52 بالتوقيت العالمي المنسق (UTC)
tgcloud.jsoncملف إعدادات المشروع في الجذر: مجلد البنية، وضع SPA، التخزين المؤقت، الرؤوس، إعادة التوجيه
الاستيراد بالمسار النسبي../schema.js بدلاً من اسم الوحدة، مع .js الإلزامي، مما يسمح للمحرر بفهم الانتقالات إلى التعريف
مجلد tgcloud/تم نقل schema.js وlib/ وhandlers/ وendpoints/ من الجذر إليه، وأصبح الجذر متاحاً للواجهة الأمامية

لم يعد التطبيق المصغر يتطلب استضافة منفصلة، أو شهادة، أو خادم مع واجهة برمجة تطبيقات (API). يتم تجميع الواجهة الأمامية بواسطة أي حزمة، وتقارن الأداة الملفات باستخدام التجزئة (hashes) وترفع فقط الملفات المعدلة. يتم إدخال العنوان الذي تطبعه push في @BotFather كعنوان للتطبيق المصغر.

ماذا تفعل بالمشروع على الإصدار 0.1

سترفض الأداة 0.2.0 العمل مع التخطيط القديم حتى يتم نقل المشروع إلى التخطيط الجديد. يتم النقل بأمر واحد:

  • npx tgcloud upgrade ينقل schema.js وlib/ وhandlers/ إلى مجلد tgcloud/. لا تتغير أسماء الوحدات (lib/cart, handlers/message).
  • تستمر عمليات الاستيراد باسم الوحدة في العمل، لكن الوثائق توصي بالانتقال إلى المسارات النسبية مع .js.

لأولئك الذين يربطون تطبيقاً مصغراً:

  • push يرفع مجلد البنية كما هو ولا يقوم بالتجميع بنفسه. إذا قمت بتشغيله بعد تعديل الواجهة الأمامية دون تجميع، فسيتم رفع الإصدار السابق إلى الإنتاج. يقوم السكريبت npm run deploy، الذي يضيفه قالب المشروع، بالتجميع أولاً ثم الرفع.
  • يفتح Telegram Web التطبيقات المصغرة في إطار (frame)، لذلك لا يمكن تعيين رأس X-Frame-Options وframe-ancestors الصارم.
  • المسار /api/ على نفس العنوان مشغول بالنقاط الطرفية (endpoints)، ولا ينبغي وضع ملفاتك الخاصة هناك.
  • immutable في ملف الإعدادات - مخصص فقط للملفات التي تحتوي على تجزئة (hash) في اسمها. سيبقي المتصفح الملفات الأخرى في ذاكرة التخزين المؤقت لمدة عام، ولن يكون هناك ما يمكن لإلغائها.
  • لا تتعرف الأداة على Next.js وNuxt وSvelteKit وAngular تلقائياً: يجب أولاً إعداد التصدير الثابت وإدخال مجلده في "source" يدوياً.

كيف يستدعي التطبيق المصغر واجهته الخلفية

في نفس اليوم، في الساعة 09:27 بالتوقيت العالمي المنسق (UTC)، قام Telegram بتحديث telegram-web-app.js، وهو السكريبت الذي يربط أي تطبيق مصغر. ظهر فيه كائن Telegram.WebApp.Serverless مع طريقة وحيدة هي call. تقوم هذه الطريقة بإجراء طلب POST إلى العنوان النسبي /api/<name>، أي إلى نفس المضيف الذي تم فتح التطبيق منه. لذلك، يعمل الاستدعاء فقط للتطبيق المصغر المستضاف على tgcloud.ai: من نطاقك الخاص، سيذهب الطلب إلى خادمك الخاص.

في رأس Authorization، يضع السكريبت السلسلة TMA وinitData بتنسيق base64. initData هي مجموعة من الحقول الموقعة من Telegram حول المستخدم والدردشة التي يفتح العميل التطبيق المصغر بها. تتحقق المنصة من التوقيع قبل تشغيل الكود، وبدونه يتلقى الطلب 401. تتلقى النقطة الطرفية (endpoint) المستخدم الذي تم التحقق منه بالفعل في ctx.initData.user. لم يعد هناك حاجة للتحقق من توقيع initData يدوياً، كما هو الحال على خادمك الخاص، ولا توجد واجهة برمجة تطبيقات (API) مفتوحة تحتاج إلى حماية لمثل هذه الواجهة الخلفية.

تنقسم الأخطاء إلى نوعين. EndpointError، الذي يتم إلقاؤه عمداً بواسطة الكود، يصل إلى العميل مع نص ومعلمات يمكن للواجهة الأمامية التفرع بناءً عليها. أي استثناء آخر يراه العميل كخطأ داخلي، ويبقى النص الحقيقي في السجلات، حتى لا تتسرب بنية الواجهة الخلفية إلى الخارج.

ما يبلغه الخادم عن نفسه بدون رمز مميز

تتصل الأداة بواجهة برمجة التطبيقات (API) على cloud.telegram.org. إحدى طرقها، /capabilities، تستجيب بدون ترخيص: تصف تخطيط المشروع، وقوالب AGENTS.md وdocs/tgcloud-sdk.md، وقائمة بأنواع التحديثات التي يمكن ربط معالج بها. هناك 27 نوعاً من هذه الأنواع. تقارن الأداة رقم مخطط المشروع بهذه الاستجابة وتحذر إذا كان الخادم يعرف بالفعل مجلدات لا تعرفها هي بعد. يوجد في كود الأداة أيضاً مفتاح TGCLOUD_BETA=1، الذي يوجه الطلبات إلى /beta. في 6 أكتوبر، تتطابق استجابة النسخة التجريبية مع الاستجابة الرئيسية.

لماذا يسمى النطاق .ai

تم تسجيل النطاق tgcloud.ai في 11 سبتمبر 2026 عبر GoDaddy. في نفس اليوم، صدرت له شهادة *.tgcloud.ai، واحدة لجميع النطاقات الفرعية من النوع app<id>. عنوان النطاق، 149.154.166.100، يقع ضمن شبكة Telegram_Messenger_Network (AS62041). يعرض جذر النطاق خطأ 404 فارغاً: لا يوجد واجهة عرض للمنصة، فقط نطاقات فرعية للتطبيقات.

اللاحقة نفسها لا تثبت شيئاً بعد: .ai هو نطاق وطني لأنغيلا، والذي تستخدمه المشاريع التقنية منذ فترة طويلة. وtgcloud.com مشغول منذ عام 2011 من قبل مالك خارجي، لذلك قد يكون الاختيار مجرد مسألة اسم متاح.

لكن المنصة بُنيت منذ اليوم الأول حول وكلاء الذكاء الاصطناعي الذين يكتبون الكود، وحول البوتات التي تولد الردود.

  • الوكيل يكتب الكود. قسم «Building with AI» موجود في الوثائق منذ يوليو. يتلقى كل مشروع جديد AGENTS.md، والذي، وفقاً للقالب نفسه، تقرأه أدوات مثل Claude Code وCursor تلقائياً، ودليل SDK في docs/. تقترح الوثائق فتح المشروع في وكيل ووصف البوت بالكلمات، وتصف هذه الخطوة بأنها الأولى.
  • البيئة مصممة للكود المُولد. لا توجد حزم npm، حزمة SDK واحدة، قواعد صارمة مثل ملف واحد لكل نوع تحديث. كلما قلّت الخيارات، قلّت أخطاء الوكيل، وتعدد الوثائق صراحةً الاتفاقيات التي تتجاهلها "توليد الكود العادي".
  • بوت يولد الرد. من بين 27 نوعاً من التحديثات التي يقبلها Serverless، يوجد stopped_message_generation وguest_message. ظهر كلاهما في Bot API في الربيع والصيف مع بقية الوظائف للبوتات القائمة على نماذج اللغة الكبيرة.
التاريخإصدار Bot APIما ظهر
31 ديسمبر 20259.3sendMessageDraft: يُظهر الرد للمستخدم أثناء التوليد
8 مايو 202610.0وضع الضيف: في رسالة واحدة يمكن دعوة ما يصل إلى ثلاثة بوتات غير موجودة في الدردشة
24 أغسطس 202610.3يمكن للمستخدم إيقاف التوليد، ويتلقى البوت تحديثاً بذلك
6 أكتوبر 2026Serverlessالتطبيق المصغر وواجهته الخلفية على منصة واحدة، AGENTS.md في كل مشروع

ما لا يتوفر في Serverless بعد هو النموذج نفسه. تتكون حزمة SDK من ثلاثة أجزاء: قاعدة البيانات (sdk/db)، وBot API (sdk/api)، وfetch. لكي يستجيب بوت على Serverless بنص من نموذج لغوي، فإنه يمر عبر fetch إلى واجهة برمجة تطبيقات (API) خارجية بمفتاحه الخاص. تشير وثائق fetch بشكل منفصل إلى القراءة المتدفقة للرد كوسيلة لتلقي مخرجات واجهة برمجة تطبيقات الذكاء الاصطناعي حسب الرموز (tokens).

لدى Telegram قدراته الخاصة للشبكات العصبية. Cocoon، وهي شبكة حوسبة سرية تعتمد على وحدات معالجة الرسوميات (GPU) مع الدفع بعملة TON، قدمها Durov في Blockchain Life 2025، ويتم تقديم موقعها الإلكتروني من نفس العنوان في شبكة Telegram مثل telegram.org. ومن هنا تأتي الفرضية: قد يصبح استدعاء نموذج مدمج، بدون مفتاح خارجي ومع الدفع عبر Telegram، الجزء التالي من حزمة تطوير البرمجيات (SDK). تتعلق الفرضية الثانية بـ @BotFather: محرر المعالجات وقواعد البيانات وملفات التطبيقات المصغرة موجود بالفعل فيه على الهاتف، ويبدو وصف البوت بالكلمات بدلاً من التعليمات البرمجية خطوة تالية لمثل هذا المحرر. لم يتم تأكيد أي من الفرضيتين حتى الآن بأي شيء سوى النطاق واتجاه التحديثات الأخيرة: ففي الوثائق، وأداة سطر الأوامر (CLI)، واستجابة /capabilities بتاريخ 6 أكتوبر، لا يوجد وحدة للشبكات العصبية.