The Bot API in one paragraph
Create an application in the Developer Portal and you get a bot token. Open the bot's invite link in a server you manage and the bot joins as a normal member. From there it does exactly what its role allows, like a person would. Your code talks to disdroc over a REST API or a real-time Socket.IO connection. Bots can send messages and rich embeds, read members and roles, kick, ban and time people out, hear when someone joins, and register their own slash commands. The Bot API guide lists every endpoint and limit.
Creating an application needs a second factor on your account: a verified email address or an authenticator app. Most accounts already have a verified email.
Community Bot Hosting
A bot normally needs a computer that stays on. Many people who want a small bot for their server do not have one. On the Bot Hosting page you paste your bot's token and your own JavaScript, and disdroc runs it.
Hosted scripts are event-driven. You export onMessage and onMemberJoin, and the runner calls them when something happens. There are two runtimes to pick from:
- isolated-vm (the default): plain JavaScript in its own isolated V8 heap. No
require, no timers.
- Node.js: a real Node process with timers and a short list of safe core modules such as
crypto and url.
What the sandbox allows
The sandbox gives your code one thing: an api object. There is no filesystem and no network access of its own in either runtime. Every api call goes to the same permission-checked endpoints a normal bot uses, so a hosted script can never do more than the bot's role allows.
The hosting runner is also a separate process from the chat server. If a script crashes or hangs, it should not take chat down with it.
Limits
- At most 60
api calls a minute per script, and 5 at a time.
- In the isolated-vm runtime, 32 MB of memory and 500 ms for each event your script handles.
- After 10 errors in a row the script is switched off, and the log tells you to fix it and turn it back on. A successful run resets the count.
Why there is a review step
An admin reviews every new script, and every edit, before it goes live.
A hosted script runs unattended with real access to your bot, and to the servers it is in. Review makes hosting slower to start. I think that is the right trade-off for something that runs on its own.
Tek paragrafta Bot API
Geliştirici Portalı'nda bir uygulama oluşturduğunda bir bot jetonu alırsın. Botun davet bağlantısını yönettiğin bir sunucuda açınca bot normal bir üye olarak katılır. Ondan sonra tıpkı bir insan gibi, yalnızca rolünün izin verdiği şeyleri yapar. Kodun disdroc'la bir REST API ya da gerçek zamanlı bir Socket.IO bağlantısı üzerinden konuşur. Botlar mesaj ve zengin kart gönderebilir, üyeleri ve rolleri okuyabilir, birini atabilir, yasaklayabilir ya da susturabilir, biri katıldığında haber alabilir ve kendi eğik çizgi komutlarını kaydedebilir. Her uç nokta ve sınır Bot API rehberi'nde.
Uygulama oluşturmak için hesabında ikinci bir doğrulama adımı gerekiyor: doğrulanmış bir e-posta adresi ya da bir doğrulayıcı uygulama. Çoğu hesabın zaten doğrulanmış bir e-postası var.
Topluluk Bot Barındırma
Bir bot normalde sürekli açık duran bir bilgisayara ihtiyaç duyar. Sunucusu için küçük bir bot isteyen çoğu kişinin böyle bir bilgisayarı yok. Bot Barındırma sayfasında botunun jetonunu ve kendi JavaScript kodunu yapıştırırsın, disdroc da çalıştırır.
Barındırılan betikler olaylarla çalışır. onMessage ve onMemberJoin fonksiyonlarını dışa aktarırsın, bir şey olduğunda çalıştırıcı onları çağırır. Seçebileceğin iki çalışma ortamı var:
- isolated-vm (varsayılan): kendi yalıtılmış V8 belleğinde düz JavaScript.
require yok, zamanlayıcı yok.
- Node.js: zamanlayıcıları olan gerçek bir Node süreci ve
crypto, url gibi kısa bir güvenli çekirdek modül listesi.
Yalıtılmış ortam neye izin veriyor
Yalıtılmış ortam koduna tek bir şey verir: bir api nesnesi. İki ortamda da kendine ait bir dosya sistemi ya da ağ erişimi yok. Her api çağrısı normal bir botun kullandığı, izinleri denetlenen uç noktalara gider. Yani barındırılan bir betik asla botun rolünün izin verdiğinden fazlasını yapamaz.
Barındırma çalıştırıcısı sohbet sunucusundan ayrı bir süreçtir. Bir betik çökerse ya da takılırsa, sohbeti de beraberinde düşürmemeli.
Sınırlar
- Betik başına dakikada en fazla 60
api çağrısı, aynı anda en fazla 5.
- isolated-vm ortamında 32 MB bellek ve betiğinin işlediği her olay için 500 ms.
- Üst üste 10 hatadan sonra betik kapatılır ve kayıt, düzeltip yeniden açmanı söyler. Başarılı bir çalışma sayacı sıfırlar.
Neden bir inceleme adımı var
Her yeni betik ve her düzenleme, yayına girmeden önce bir yönetici tarafından incelenir.
Barındırılan bir betik gözetimsiz çalışır ve botuna, botun bulunduğu sunuculara gerçekten erişir. İnceleme, barındırmanın başlamasını yavaşlatıyor. Kendi kendine çalışan bir şey için bunun doğru ödünleşim olduğunu düşünüyorum.