Mahi in Tech

یه به‌روزرسانی کوچیک روی قیچی داشتیم. البته با توجه به ۲۰ تا ایشویی که زحمت کشیدید باز کردید (🥲)، اون‌قدرها هم کوچیک نموند :D مهم‌ترین تغییرات این نسخه: * عکس مخاطب‌ها: دیگه همه‌جا فقط آواتارهای حروفی رو نمی‌بینید و عکس مخاطب‌ها داخل برنامه نمایش داده می‌شه. * پوشه‌بندی گفتگوها: می‌تونید پیام‌ها رو توی پوشه‌های دلخواه یا پوشه‌های آماده دسته‌بندی کنید تا همه‌چیز مرتب‌تر باشه. * پین کردن چت‌ها: گفتگوهای مهم رو پین کنید و ترتیبشون رو خیلی راحت با کشیدن تغییر بدید. * کپی هوشمند کدها: کدهای یک‌بارمصرف با دقت بالاتری تشخیص داده می‌شن تا با یک دکمه کپی‌شون کنید. برای رمز پویای بانکی هم قابلیت کپی خودکار اضافه شده. * زمان‌بندی و لغو ارسال: علاوه بر زمان‌بندی ارسال پیام، می‌تونید ارسال رو چند ثانیه به تأخیر بندازید تا در صورت پشیمونی، قبل از رفتن پیام لغوش کنید. * سطل زباله: پیام‌های حذف‌شده به سطل زباله منتقل می‌شن تا هر وقت نیاز داشتید بتونید برشون گردونید. * رفع باگ‌ها: مشکل لود نشدن بعضی گفتگوها و نمایش ناقص پیامک‌ها هم کامل برطرف شده. راستی، به لطف +۱۰۰ گزارشی که خودتون ارسال کردید، مدل تشخیص پیامک‌های اسپم به نسخه‌ی ۵ ارتقا پیدا کرده و الان بهتر از نسخه‌ی قبل عمل می‌کنه 📥 دانلود و مشاهده‌ی تغییرات (نسخه‌ی 0.5.3): github.com/MahdiyarGHD/GheychiApp/releases/tag/0.5.3

آندری کارپتی (Andrej Karpathy) یه توییت جالب زده در مورد اینکه با قوی‌تر شدن LLMها، کار اصلی ما دیگه تولید محتوا نیست، بلکه فهمیدن و نظارت روی خروجی‌هاشون می‌شه. یعنی مدل‌ها دارن بیشتر و بیشتر کار سنگین رو خودشون انجام می‌دن و ما باید بریم سمت لایه‌های بالاتر و بفهمیم واقعاً چی دارن می‌گن. چند تا ترفند باحال و عملی پیشنهاد داده که من هم کم‌کم دارم امتحانشون می‌کنم: نوشتن با ASD-STE100: بگید مدل مطلب رو با زبان کنترل‌شده ASD-STE100 بنویسه. این استاندارد اصلش برای مستندات نگهداری هواپیما و تجهیزات هوافضا طراحی شده و قوانین خیلی سختگیرانه‌ای داره (جمله‌های کوتاه، فعل‌های مشخص، دیکشنری محدود، بدون ابهام و استعاره‌های پیچیده). نتیجه‌ش اینه که متن خیلی تمیز، مستقیم و خوانا می‌شه. اگر خیلی خشک شد، می‌تونید بگید «۸۰ درصد نزدیک به ASD-STE100» تا یه کم نرم‌ترش کنه. برای توضیح‌های فنی و پیچیده عالیه، چون مغزتون کمتر خسته می‌شه. نمودار و دیاگرام به جای متن: به جاش مستقیم ازش بخواید دیاگرام، flowchart یا mermaid یا تصویر مفهومی بسازه. مغز ما اطلاعات بصری رو خیلی سریع‌تر پردازش می‌کنه و پارس کردنش راحت‌تره. مخصوصاً وقتی موضوع پیچیده باشه، یه دیاگرام خوب می‌تونه کل ایده رو در چند ثانیه منتقل کنه، در حالی که متن ممکنه چند پاراگراف طول بکشه. خروجی به صورت HTML: بگید خروجی رو به صورت HTML کامل بده. مدل‌های جدید واقعاً تو فرانت‌اند قوی شدن و می‌تونن صفحه‌های وب قشنگ، اینتراکتیو، با انیمیشن و استایل مدرن بسازن. به جای یه متن خشک، یه تجربه‌ی تعاملی می‌گیرید که می‌تونید روش کلیک کنید، اسکرول کنید یا حتی چیزایی رو تست کنید. برای فهمیدن مفاهیم پیچیده خیلی کمک‌کننده‌ست. ویدیوهای explainer سفارشی (بهترینش اینه!): کارپتی می‌گه بیشتر از همه به این فرمت امیدواره. از مدل بخواید یه ویدیوی کامل و اختصاصی به سبک 3Blue1Brown بسازه (همون انیمیشن‌های ریاضی و مفهومی تمیز و قشنگ). می‌تونید بگید از API کی ElevenLabs برای narration استفاده کنه یا جایگزین‌های رایگان/لوکال پیدا کنه. اینطوری برای هر موضوعی که بخواید، یه ویدیوی آموزشی شخصی‌سازی‌شده می‌سازید که قبلاً ساختنش زمان و هزینه‌ی دیوانه‌کننده‌ای داشت.خلاصه‌ش اینه که هوش مصنوعی داره انقدر زیاد و ارزون می‌شه که می‌تونیم ازش artifactهای بزرگ و دورریختنی بسازیم (وب‌اپ، ویدیو، دیاگرام‌های پیچیده و غیره) که قبلاً اصلاً به‌صرفه نبود. کار ما داره می‌ره به لایه‌های بالاتر abstraction و oversight، و جالب اینجاست که خود LLMها می‌تونن تو همین بخش هم کمک‌مون کنن. به نظرم خیلی نکته‌ی درستیه، مخصوصاً برای ما که هر روز با اینا کار می‌کنیم. حتماً امتحان کنید و نتیجه‌ش رو بگید 🔥 پ.ن: آندری کارپتی یکی از استادای واقعی و پیشگام‌های حوزه LLM و deep learning حساب می‌شه. قبلاً مدیر AI تسلا بوده، از بنیان‌گذاران اولیه OpenAI، و یکی از بهترین‌ها در توضیح شفاف و عمیق مفاهیم هوش مصنوعیه. وقتی حرف می‌زنه، معمولاً ارزش گوش دادن داره. لینک توییت: https://x.com/karpathy/status/2105819303471976479

آپدیت جدید قیچی ✂️ این آپدیت یه تغییر کوچیک داره: قیچی رو از پایه با یه تکنولوژی جدید بازنویسی کردم :| البته زبان و کدبیس تقریبا همونه؛ صرفا از مائویی مهاجرت کردیم به Avalonia. علت‌ش رو توی پست‌های بعدی توضیح می‌دم. ظاهر برنامه هم تقریبا همونه، ولی الان خیلی روون‌تر و سبک‌تر شده. چیزایی که حس می‌کنید: - حالت روشن و تیره شیک‌تر شدن و حالا می‌تونید رنگ اصلی برنامه رو هم از بین ۱۰ رنگ مختلف، خودتون انتخاب کنید. اندازه‌ی متن‌ها هم توی تنظیمات دست خودتونه. - لینک‌ها و شماره‌تلفن‌ها حالا توی پیام‌ها بهتر قابل تشخیص‌ان. - حالا می‌تونید از برنامه‌های دیگه هم به قیچی برسید و لینک‌های مرتبط با SMS به‌درستی توی قیچی باز می‌شن. - نمایش فارسی روی هر دو زبان بهتر شد و متن‌های فارسی همیشه با فونت وزیرمتن نمایش داده می‌شن. - یک سری از باگ‌ها، از جمله مواردی که خودتون گزارش کرده بودین، هم برطرف شدن. هنوز چند مورد ایشوی باز داریم که ترکیبی از باگ‌ها، پیشنهادها و فیچرهای جدیدن. اون‌ها رو هم کم‌کم رسیدگی می‌کنم. بازم احتمالا باگ دارم 🙃 اگه چیزی دیدید، حتما بهم بگید. دانلود و مشاهده‌ی تغییرات: 🔗 github.com/MahdiyarGHD/GheychiApp/releases/tag/0.4.3 همچنین اگر درحال حاضر برنامه رو نصب دارید، می‌تونید از بخش About گزینه‌ی Check for update رو بزنید تا نسخه‌ی مناسب با دستگاه‌تون رو دانلود کنه.

🚨 تلگرام دسکتاپ رو فورا آپدیت کنید (ورژن‌های قبل 7.2.9 باگ بحرانی دارند) به‌دلیل Escape نشدن کاراکتر ; در لینک‌های tg:// و اجرای مستقیم دستورات IPC، اتکر می‌تونه فقط با یک کلیک، فایل‌های محرمانه سیستم (سشن‌های tdata، کلیدهای SSH، سشن‌های مرورگر و والت‌ها) رو بدون تایید شما مستقیما بدزده. اقدامات فوری: کلاینت رو سریع به نسخه 7.2.9 یا بالاتر آپدیت کنید. حتماً Local Passcode تلگرام رو ست کنید تا دایرکتوری tdata انکریپت بشه. تا انتشار پچ، از کلاینت‌های تردپارتی/غیررسمی استفاده نکنید. CVE-2026-107181

یک توسعه دهنده اسپانیایی با استفاده از هوش مصنوعی، تمامی ابزارهای ادوب را مهندسی معکوس کرده و در راست بازنویسی کرده است. https://getartcraft.com/apps شما کاربران پارچ می‌توانید این ابزارها را تست کرده و نتایج آن را با ما به اشتراک بگذارید. درنهایت نیز ما نقش خود را برای رفع مشکلات این ابزارها با زبان فارسی بواسطه مشارکت در پروژه بالادستی آن ایفا خواهیم کرد. @ParchLinux | پارچ لینوکس

یه سری مشکلات پرفورمنسی روی UI هم بچه‌ها گفتن، که متوجه‌شون هستم :)) و اوکی‌شون می‌کنم. وقتی Back-End Developer سعی می‌کنه UI بزنه:

یه نکته‌ای که یکی از دوستان گفت این هست‌ش که روی گوشی‌های سامسونگ و شاید هم حتی بقیه مدل‌ها، شما نمی‌تونین اپ ای که از گوگل پلی نصب نشده رو نرم‌افزار پیش‌فرض SMS کنین. که خب ظاهرا برای حل‌ش باید از تنظیمات اپ، گزینه‌ی Allow restricted settings رو فعال کنین.

خب ظاهرا روی بعضی از دستگاه ها به خاطر این‌که Google Play Protect هنوز اپ رو نمی‌شناسه اجازه‌ی نصب رو نمی‌ده 🥲 و تا تایید بشه باید برای نصب از هفت‌خوان گوگل رد بشیم.

هنوز ندیدیم ولی 🥱

* با هر نسخه، آخرین ورژن مدل به‌صورت خودکار از مخزن دیتاست در گیت‌هاب دریافت و باندل می‌شه. در صورت به‌روزرسانی مدل، امکان ارتقای اون بدون نیاز به نصب مجدد برنامه هم وجود داره. * مخاطبین به‌صورت پیش‌فرض از تشخیص اسپم مصون هستن. در صورت نیاز، می‌تونید این مصونیت رو برای افرادی که در مخاطبین‌تون نیستن هم فعال کنید. * می‌تونید میزان حساسیت مدل رو از تنظیمات تغییر بدید. پیش‌فرض روی حالت Balanced هست که فکر می‌کنم با مدل فعلی، همین حالت کافی باشه. * روزانه یک بار گزارشی از پیامک‌های اسپم نمایش داده می‌شه تا اگر پیامی به‌اشتباه به‌عنوان اسپم تشخیص داده شده بود، از دست نره. زمان نمایش این گزارش از تنظیمات قابل تغییره و امکان غیرفعال کردنش هم وجود داره.

‍ اولین نسخه‌ی «قیچی» منتشر شد! ✂️ راست‌ش چند وقتی هست که پیامک‌های تبلیغاتی و اسپم، شدیدا اعصابم رو خرد می‌کرد و دیگه با دلار ۲۷۰ تومنی، تحملِ حواس‌پرتی برای اس‌ام‌اسِ کد تخفیف ۵ هزار تومنی اسنپ و یا به خصوص وصایای امام 🍌 ممکن نبود. برای همین تصمیم گرفتم پروژه‌ای رو که اولین کامیتش مربوط به ۲ سال پیش بود و بعد از اون هم دیگه ادامه پیدا نکرد، بالاخره به سرانجام برسونم. «قیچی» یک اپلیکیشن مدیریت پیامک اندرویدی هست که با MAUI + ML.NET توسعه داده شده و تنها یک هدف داره: خفه کردن پیامک‌های اسپم و تبلیغاتی. قیچی به عنوان اپلیکیشن پیش‌فرض گوشی‌تون تنظیم می‌شه و دقیقاً همون کاری رو می‌کنه که هر SMS Manager دیگه‌ای انجام می‌ده؛ با این تفاوت که یک مدل ML خیلی سبک هم داخلش تعبیه شده که هدفش تشخیص پیامک‌های تبلیغاتی در کسری از میلی‌ثانیه 🫪 و به‌صورت کاملا آفلاین روی دیوایس شخص هست. بنابراین هیچ‌ داده‌ای به سمت سرور ارسال نمی‌شه و همه‌چیز کاملا آفلاین و امنه. ضمن این‌که تمام بخش‌های پروژه اعم از دیتاست، سورس اپلیکیشن و مدل ML اپن‌سورس هستن و بیلد برنامه هم مستقیما توسط GitHub Actions گرفته می‌شه. یعنی این‌طوری بگم که خیالتون از هر بابت راحت باشه. دیتاست فعلی در حال حاضر خیلی جامع نیست و حدود ۶ هزار پیامِ لیبل‌خورده رو شامل می‌شه؛ اما طبق برآورد و تست‌هایی که داشتم، همین دیتاست کوچیک هم (که از منابع مختلفی جمع‌آوری شده) تا حد خوبی جواب‌گوی نیاز برنامه است. همچنین داخل برنامه این امکان تعبیه شده که شما به‌صورت گزینشی (و با حذف خودکار یا دستیِ اطلاعات حساس)، پیامک‌های تبلیغاتی یا پیامک‌های غیرتبلیغاتی‌ای که به اشتباه تبلیغ تشخیص داده شدن رو گزارش کنید تا این دیتاست به مرور زمان کامل‌تر بشه و عملکرد مدل ارتقا پیدا کنه. (اگر هم نکردین چالشی نیست،‌ خودم می‌کنم 😭) نسخه‌ی فعلی در واقع حداقل نسخه‌ی قابل ارائه هست و احتمالا باگ‌های زیادی خواهد داشت. ولی خب از اون‌جایی که مورد استفاده‌ی روزمره‌ی خودم هست، به مرور زمان بهبود پیدا می‌کنه. 🔗 سورس پروژه و توضیحات تکمیلی: https://github.com/MahdiyarGHD/GheychiApp 📥 دانلود نسخه‌ی اولیه از گیت‌هاب: https://github.com/MahdiyarGHD/GheychiApp/releases اگر دوست داشتید، با گزارش باگ، مشارکت در توسعه یا حتی یک ⭐️ روی گیت‌هاب می‌تونید کمک کنید قیچی بهتر بشه.

این trickـهای AI هم هرروز عجیب‌تر می‌شه ها. یه LLM که ورودی عکس قبول نمی‌کنه رو گذاشته بودم یک تسک رو انجام بده، و خب بعید می‌دونستم که به عکس نیاز پیدا کنه. یه مدت چک‌اش نکردم و وقتی برگشتم دیدم یه‌سری اسکرین‌شات گرفته و یه اسکریپت نوشته که اون‌ها رو به ASCII Art تبدیل می‌کنه و سعی می‌کنه بفهمتشون :)))

از این به بعد داخل کلاد کد، اگر یه وقت وسط انجام یه تسک به لیمیت ۵ ساعته برخورد کنید، دیگه اون تسک رو همون‌جا متوقف نمی‌کنه و صرفاً سعی می‌کنه با استفاده از لیمیت هفتگی‌تون، زودتر جمع‌وجورش کنه. (البته ظاهرا برای کاربران Pro, صرفا یک بار در هفته قابل استفاده‌ست)

وقتی صحبت از پیاده‌سازی Rate Limiting (مخصوصا مدل‌هایی مثل Token Bucket یا Leaky Bucket) می‌شه، معمولا اولین چالش، مدیریت State هست؛ اینکه همزمان باید تعداد توکن‌های باقی‌مونده و زمان آخرین Refresh رو نگه داریم و حواس‌مون به Race Condition هم باشه. الگوریتم GCRA (Generic Cell Rate Algorithm) که توی سیستم‌های توزیع‌شده استفاده می‌شه، این مسئله رو با یک ترفند ریاضی خیلی ساده حل کرده: حذف مفهوم توکن و جابجایی همه‌چیز به بردار زمان. ایده اصلی اینه: به جای اینکه چک کنیم کاربر چند تا توکن داره یا شمارنده رو ریست کنیم، یک متغیر عددی به اسم TAT (Theoretical Arrival Time) نگه می‌داریم؛ یعنی «زمان تئوریک رسیدن درخواست بعدی». منطق کارکرد به چه صورته؟ فرض کنید لیمیت سیستم، ۱ درخواست در ثانیه باشه و به کاربر اجازه دادید تا سقف ۳ درخواست هم ترافیک ناگهانی (Burst) داشته باشه: هر بار که یک درخواست تایید می‌شه، TAT به اندازه‌ی فاصله‌ی زمانی مجاز بین درخواست‌ها، به آینده هل داده می‌شه. اگر کاربر چند درخواست پشت سر هم بفرسته، TAT جلوتر و جلوتر می‌ره. در واقع داریم میزان «جلو افتادن» جریان درخواست‌ها از نرخ مجاز رو اندازه می‌گیریم، و تا وقتی فاصله‌ی بین زمان فعلی و TAT از محدوده‌ی مجاز Burst بیشتر نشده باشه، درخواست‌ها تایید می‌شن. اگر این فاصله از محدوده‌ی مجاز عبور کنه، کاربر درجا خطای 429 می‌گیره و مهم‌تر اینکه TAT هم برای درخواست ردشده تغییر نمی‌کنه. به محض اینکه کاربر چند ثانیه دست نگه داره، زمان فعلی به TAT نزدیک‌تر می‌شه و عملاً ظرفیت Burst به‌صورت خودکار آزاد می‌شه؛ بدون اینکه هیچ Job پس‌زمینه‌ای نیاز باشه یا کدی برای ریست کردن شمارنده‌ها اجرا بشه. در ساده‌ترین حالت، منطق چیزی شبیه به اینه:

if now < TAT - tolerance:
    reject
else:
    TAT = max(now, TAT) + interval
    accept

و قبل از آپدیت، بررسی می‌کنیم که آیا TAT در محدوده‌ی مجاز قرار داره یا نه. نکته‌ی مهم اینه که مقدار دقیق این محدوده به نحوه‌ی تعریف Burst/Tolerance در پیاده‌سازی بستگی داره. چرا این مدل جذابه؟ ۱. استیت تک‌مقداری: کل وضعیت هر کاربر فقط یک عدد ساده (Timestamp) هست که توی ردیس می‌تونه به صورت یک String ساده ذخیره بشه. ۲. اجرای اتمیک و جلوگیری از Race Condition: خود GCRA به‌تنهایی Race Condition رو حذف نمی‌کنه؛ چیزی که این مشکل رو حل می‌کنه، اجرای اتمیک کل منطق Check + Update هست. مثلا می‌تونیم این کار رو با یک اسکریپت چند خطی Lua داخل Redis انجام بدیم، بدون اینکه چند دستور جداگانه بین Read و Write داشته باشیم. ۳. مدیریت تمیز TTL: چون زمان موردنیاز برای نگه داشتن State قابل محاسبه است، می‌تونیم TTL کلید رو بر اساس زمانی تنظیم کنیم که TAT و محدوده‌ی Burst دیگه برای تصمیم‌گیری لازم نیستن. در نتیجه، کلیدها به‌صورت خودکار expire می‌شن و نیازی به Job یا فرآیند جداگانه برای پاک‌سازی State نداریم. در نهایت، جذابیت اصلی GCRA این هست که به جای نگه داشتن چند متغیر مثل Token Count، Last Refill و Timestamp، کل State رو به یک مفهوم زمانی تبدیل می‌کنه.

روز «مهندس یه ویندوز برامون نصب می‌کنی؟» مبارک.

توی سیستم‌های High-Load، یکی از چالش‌های همیشگی اینه که خیلی سریع بفهمیم یک دیتای خاص وجود داره یا نه. اگر بخوایم برای هر چک کردن ساده به‌طور مستقیم سراغ دیتابیس بریم یا حتی به صورت کامل روی Cache حساب کنیم، هم منابع زیادی درگیر می‌شه و هم Latency بالا میره. یکی از رویکردهای بهینه و جذاب برای حل این مسئله، استفاده از Bloom Filter هست. بلوم فیلتر یک Data Structure احتمالاتی 🥴 هست که با کمترین میزان مصرف مموری و سرعت خیره‌کننده، بهمون میگه یک آیتم وجود داره یا نه. سناریوی واقعی: انتخاب یوزرنیم در تلگرام تلگرام صدها میلیون کاربر داره. وقتی شما موقع ثبت‌نام داری یوزرنیم تایپ می‌کنی، به ازای هر کاراکتری که می‌زنی باید چک بشه که این یوزرنیم آزاد هست یا نه. اگر تلگرام بخواد برای هر تایپ شما یک کوئری به دیتابیس اصلیش بزنه، دیتابیس در عرض چند ثانیه از حجم درخواست‌ها نابود می‌شه! راه‌حل چیه؟ تلگرام تمام یوزرنیم‌های ثبت‌شده رو میده به یک Bloom Filter که توی رم قرار داره. وقتی شما یوزرنیم جدید رو تایپ می‌کنی، بلوم فیلتر در کسری از میلی‌ثانیه چک می‌کنه. اگر بگه «این یوزرنیم به‌طور قطع وجود نداره»، تلگرام همون لحظه تیک سبز رو بهت نشون میده و دیگه کاری به دیتابیس نداره (صرفه‌جویی عظیم در منابع). اما اگر بلوم فیلتر بگه «ممکن هست وجود داشته باشه»، تلگرام تازه اونجا میره از دیتابیس می‌پرسه که "مطمئنی این یوزرنیم پر شده؟" تا وضعیت دقیق رو بهت بگه. (که البته تلگرام چنین کاری نمی‌کنه و مثال بود=)) حالا این بلوم فیلتر چطور کار می‌کنه؟ پشت صحنه، Bloom Filter در واقع فقط یک آرایه طولانی از Bitهاست که اول کار همه‌شون صفر هستن. در کنارش، چند تا تابع Hash مستقل و سریع هم داریم. وقتی می‌خوایم یک دیتای جدید رو به سیستم اضافه کنیم، این دیتا رو به توابع Hash می‌دیم. خروجی این توابع، ایندکس‌هایی از همون آرایه بیت‌هاست. بعد میریم اون ایندکس‌ها رو برابر با ۱ قرار می‌دیم. موقع جستجو دوباره همون دیتای ورودی رو هش می‌کنیم و ایندکس‌ها رو چک می‌کنیم: ۱. اگر حتی یکی از اون بیت‌ها صفر باشه، سیستم با قطعیت ۱۰۰٪ میگه این دیتا «به‌طور قطع وجود نداره». ۲. اگر همه بیت‌ها ۱ باشن، سیستم میگه این دیتا «احتمالا وجود داره». چرا می‌گیم احتمالا؟ چون ممکنه اون بیت‌ها قبلا به‌خاطر هش شدنِ دیتای دیگه‌ای ۱ شده باشن (همون پدیده Hash Collision). یعنی ما توی Bloom Filter خطای False Positive داریم، اما False Negative اصلا نداریم. البته که این ساختار محدودیت‌های خودش رو هم داره؛ به‌طور مثال حذف کردن یک آیتم از بلوم فیلتر در پیاده‌سازی‌های استانداردش یه‌جورایی غیرممکنه؛ چون با صفر کردن یک بیت، ممکن هست دیتای دیگه‌ای که از همون بیت استفاده می‌کرده رو هم خراب کنیم. در نهایت، در ازای پذیرش اون احتمال کمِ False Positive، سیستمی به دست میاد که می‌تونه وجود میلیون‌ها رکورد رو فقط با چند مگابایت RAM در لایه Application چک کنه و زیرساخت دیتابیس شما رو از شر درخواست‌های بیهوده نجات بده.

توی شرایط فعلی به‌خوبی متصل می‌شه، استفاده کنین.

نسخه جدید Oblivion منتشر شد! هسته کلاینت کاملا تغییر کرده و Aether جایگزین هسته قبلی شده؛ با پشتیبانی از MASQUE H2/H3، WARP، GOOL و قابلیت Chain با Psiphon. برای شبکه‌های محدود هم روی Scan و Obfuscation کار زیادی شده تا اتصال پایدارتر و ساده‌تر باشه. https://github.com/bepass-org/oblivion/releases/tag/v8 🐙 @RepoFA

نپرسید چرا، که هنوز نمیدونم 🥱 github.com/MahdiyarGHD/Ink-To-Math