Bemærk: Denne oversættelse er kun til orientering. I tilfælde af uoverensstemmelse mellem den engelske tekst og denne oversættelse har den engelske version forrang.

Brugernes privatliv og sikkerhed er høje prioriteter for Discord, herunder ved brug af bots. I august annoncerede vi, at adgang til meddelelsesindhold for bots kræver verifikation og privilegeret gateway-godkendelse for enhver bot, der opererer i 100 servere eller mere. Vores mål er at sikre, at besked privatliv er standardtilstanden i verden for bots, der opererer i stor skala på Discord, og at adgang til beskedindhold kun gives på grundlag af behovet for en bots kernefunktionalitet.

Der er naturligvis masser af brugssager, hvor en bot har et legitimt behov for at få adgang til meddelelsesindhold. Nogle almindelige vi ser:

• Indholdsmoderering
• Gameplay interaktioner
• Maskinlæring og neuro-sproglige applikationer
• Arkivfunktioner i fællesskabet

❓ Har du spørgsmål om din brugssag? Åbn en billet på https://dis.gd/contact ved hjælp af Bot & API Developer Support-formularen, eller spørg på Discord Developers-serveren!

For at blive godkendt til verifikation til brug af beskedindhold skal en bots brugssag for at få adgang til meddelelsesindhold:

• give brugerne en unik, overbevisende og/eller transformerende oplevelse;
• være ikke-invasiv og sætte brugerens privatliv og sikkerhed i centrum;
  • Giv et link til din privatlivspolitik, så brugerne let kan finde dem.
• ikke kan overføres til vores nye interaktionsmuligheder;
• være relevant for bottens mission og eksisterende funktionssæt
• ikke repræsentere nogen væsentlig indvirkning på vores infrastruktur.

Vi anbefaler, at alle bots begynder at migrere til vores nye interaktionsmuligheder, hvor det overhovedet er muligt, selv hvis det er godkendt til meddelelsens hensigt.

Hvad dækker denne artikel? 

• Baggrund
• Kriterier for godkendelse
  • Enestående
  • Overbevisende
  • Transformativ
  • Ikke-invasiv
• Mulighed for migration
• Bibliotekproblemer
• Relevans for bot
• Påvirkning af infrastrukturen
• Rapportering
• Håndhævelse

Baggrund

⚠️ Hvis din Bot fungerer på 100 servere eller færre, påvirker denne ændring dig ikke.

Hvis du læser dette, skyldes det, at du har hørt de store nyheder - fra april 2022 kræver meddelelsesindhold verifikation og privilegeret gateway hensigt-godkendelse for enhver bot, der opererer på over 100 servere. Hvis din bot opererer på færre end 100 servere, påvirker denne ændring dig ikke.

Vores mål er at sikre, at privatlivet er standardtilstanden i verden for bots, der opererer i stor skala på Discord, og at adgang til beskedindhold kun gives på grundlag af behovet for en bots kernefunktionalitet. Adgang til beskedindhold forsvinder ikke. Der vil altid være unikke, overbevisende og transformerende funktioner, der kræver adgang til beskeder på en server: fra moderation til gameplay, til ting vi ikke engang kan forestille os endnu. Bots vil fortsat have adgang til alle meddelelser, der specifikt @nævner dem, samt til DM'er direkte med botten, uanset godkendelse af meddelelseshensyn.

Hvis en bot, der opererer i stor skala, har adgang til bulkmeddelelser, skal vi sikre os, at den med god grund har denne adgang. Godkendelse af meddelelsesindhold betyder også, at bot bruger meddelelser på måder, der ikke kan migreres til vores nyere interaktionsmuligheder. Håndtering af meddelelsesdata er et kæmpe ansvar og kan i høj grad påvirke privatliv og sikkerhed for brugere på Discord.

Nedenfor forklarer vi, hvad de forskellige ovennævnte kriterier betyder, og hvorfor de er vigtige for vores tankeproces.

Kriterier for godkendelse

Vi har rodfæstet vores godkendelsesfilosofi i tre grundlæggende principper. Vi leder efter funktioner, der er unikke, overbevisende og transformerende. Lad os tale om, hvad det generelt betyder, og hvad det vil betyde for meddelelser fremad.

Unik 

📝 Vi anser UNIK for at være funktioner, der i øjeblikket ikke er tilgængelige i nogen kapacitet indenfor klienten.

Hvis en funktion, du bygger, er noget, klienten allerede gør til en vis grad, vil vi sandsynligvis ikke give dig hensigt godkendelse til denne funktion.

• Eksempel: Lad os bruge Guild Presences og aktivitetsdata som et eksempel på, hvordan vi anvender disse kriterier generelt. Når du arbejder med Guild Presences, og din eneste brugssag er at tælle, hvor mange brugere der er online på en given server. Klienten gør allerede dette - du kan bare tjekke sidebjælken i enhver kanal med @everyone adgang! Fordi klienten gør dette næsten identisk, så ville vi ikke betragte din brugssag som unik, og derfor ville vi ikke give dig Presences -adgang udelukkende for at levere den slags funktioner.
  
  • Bemærk, at hvilke funktioner, der er "unikke", kan ændre sig som klienten gør. Vi forbeholder os retten til at nægte eller fjerne Privilegeret hensigt, når denne funktionalitet afsløres via klienten.

Overbevisende

📝 Vi tænker på OVERBEVISENDE som funktioner, der er klare, selvforklarende og umiddelbart forståelige, hvorfor denne funktion skulle eksistere, og hvor den ville være nyttig.

Af alle vores kriterier, så er funktioner, der betragtes som overbevisende, måske de mest nuancerede, hvorfor vi opfordrer dig til at dele så mange detaljer som du overhovedet kan.

Beskriv dine funktioner i dybden. Fortæl os, hvorfor du synes, at dine funktioner er fede, og hvorfor du synes, at dine brugere har brug for dem. Vi elsker det, når du fortæller os historier om den software, du laver, så fortæl os dine historier!

Med dette i tankerne, så vil blot anmode om godkendelse af meddelelser, så du kan opretholde brugerdefinerede præfikser eller traditionelle kommandogrænseflader, resultere i et afslag, da vi ikke mener, at det er en overbevisende brugssag i sig selv.

Transformativ

📝 Vi betragter TRANSFORMATIV som at bruge de oplysninger, du indsamler gennem meddelelseshensigter, til at levere nye funktionalitet eller funktioner.

Bare det at genoplive det beskedindhold, du indsamler på en ny måde, betragtes generelt ikke som "transformativt". Ofte vil udviklere anmode om godkendelse af hensigter, blot så de kan dele brugeroplysninger, serverdata eller anden statistik. For det meste er den slags ikke transformativt. 

Eksempel: Lad os bruge Guild Presences og aktivitetsdata som et eksempel på, hvordan vi generelt anvender disse kriterier. Hvis du f.eks. Bare viser, hvad en persons aktivitetsstatus er med en slags !aktivitet [bruger-id her], så er det simpelthen at genskabe funktionalitet, der findes i klienten. Men hvis du ser på en persons aktivitetsdata og handler ud fra dem på måder, som klienten ikke kan, ville det være transformativt. For eksempel en kommando, der indeholder tekster til en sang, der er nævnt i en persons aktivitetsstatus “Afspilles nu”.

Ikke-invasiv

Udover at lede efter funktioner, der er unikke, overbevisende og transformerende, kræver vi også, at brugssager respekterer brugernes privatliv og sikkerhed.

Hvis du har til hensigt at indsamle brugerdata for at give en vis grad af funktionalitet, skal du:

• Sørg for, at du overholder alle relevante love om fortrolighed. Dette inkluderer tydeligt at oplyse, hvilke data du indsamler, og hvordan du bruger dem.
• Send en privatlivspolitik offentligt og gør den tilgængelig for brugerne (og giv os et link).
• Tillad brugere at fravælge at give dig disse data, selvom det betyder, at de ikke kan deltage i funktionen.
• Giv en tilgængelig måde for brugerne at anmode om adgang til og sletning af deres data.

Som en påmindelse, så er det dit ansvar at sikre, at du har gennemgået og overholder vores Udviklerbetingelser, Udviklerpolitik,  Brugerbetingelser og Fællesskabsretningslinjer.

Eksempel: Lad os bruge Guild Presences og aktivitetsdata som et eksempel på, hvordan vi generelt anvender disse kriterier. Indsamling af en brugers Presence informationer for at indsamle en grov ide om, hvilken tidszone de befinder sig i baseret på deres tid brugt aktivt på platformen, uden at brugerne frivilligt giver dig disse oplysninger. De mest invasive funktioner er dem, der bruges til at levere reklame og marketing inden for servere, hvilket allerede er eksplicit ikke tilladt i vores Udviklerpolitik.

Mulighed for migration

Når vi gennemgår anmodninger om meddelelsesindhold, vil vi overveje muligheden for at migrere din angivne funktionalitet til interaktioner, hvor det er muligt. Vores mål er enten at bevare funktionaliteten af ​​de funktioner, der passer til ovenstående kriterier, som de eksisterer nu, eller at hjælpe dig med at migrere disse funktioner til interaktioner, hvor det er muligt.

Hvis en funktion ikke kan migreres til interaktioner på nogen måde og opfylder vores andre kriterier, vil du sandsynligvis få godkendelse af beskedindhold. Hvis en funktion kan migreres til interaktioner med en vis grad af ændringer af din brugeroplevelse, vil vi sandsynligvis hælde til at hjælpe dig med at migrere denne funktionalitet i stedet for at give dig beskedgodkendelse.

Bibliotekproblemer

Når vi diskuterer gennemførligheden af ​​migration, så er det naturligvis vigtigt for os at overveje virkningen af ​​fællesskabsdrevne biblioteker og deres anvendelse af vores interaktionsmuligheder. Vi har arbejdet med libdev-fællesskabet siden begyndelsen af ​​sommeren for at prøve at hjælpe dem med at adoptere interaktioner så hurtigt og gnidningsløst som muligt.

Når det er sagt, vil vi ikke være i stand til at give beskedhensigter i tilfælde, hvor din eneste blokering, der forhindrer migrering, er mangel på support til interaktioner i dit valgte udviklingsbibliotek.

• Hvis du er på et bibliotek, der ikke understøtter interaktioner, og dine funktioner ellers ikke er unikke eller overbevisende nok til at retfærdiggøre godkendelse af meddelelseshensyn, så kan du overveje at undersøge biblioteksudvidelser, alternative biblioteker eller alternative sprog, hvor det er muligt.

Bots vil fortsat have adgang til alle meddelelser, der specifikt @omtaler dem, såvel som til DMs direkte med botten, uanset meddelelsens hensigtsgodkendelse. Hvis du udvikler med et bibliotek, der ikke understøtter migrering til interaktioner, så kan du stole på denne adgang som en reserve.

Relevans for bot

Vores mål er at sikre, at udviklere kun får adgang til meddelelsesindhold, hvor det er nødvendigt at levere funktioner, der er direkte relevante for deres brugere. Med det i tankerne vil vi med hensyn til meddelelseshensigt være lidt mere kræsne om, hvorvidt en foreslået funktion er relevant for din bots overordnede angivne mål.

Planlæg at forklare, hvorfor din bot især har brug for adgang til meddelelsesindhold for at aktivere den specifikke funktionalitet.

🛑 Vi forbeholder os retten til periodisk revidere rettigheder og verifikation til enhver bot tilfældigt for at sikre, at de overholder vores politikker. Vi kan tilbagekalde bekræftelse for en verificeret bot, hvis botten ændrede sig væsentligt fra de angivne mål og formål i den oprindelige verifikationsansøgning og ikke er blevet opdateret.

Påvirkning af infrastrukturen

• Funktioner, der stimulerer spam.
• Funktioner, der lægger unødig belastning på vores databaser (f.eks. at hamre den samme ressource meget hurtigt for evigt).
• Funktioner, der stimulerer selfbotting. 

Rapportering

Hvis du finder en bot, der ikke er i overensstemmelse med denne politik, så bedes du rapportere den til os ved at udfylde formularen her: https://dis.gd/report

Håndhævelse 

Denne politik håndhæves af vores Developer Supportteam. Teamet gennemgår din ansøgning, kan anmode om yderligere oplysninger og kan træffe beslutningen om at verificere, ikke verificere eller tilbagekalde verifikation afhængigt af bottens overholdelse af denne politik og alle andre gældende vilkår og politikker.

Spørgsmål, kommentarer, bekymringer? Vi har kontaktformularen for Developer Support og Discord Developers-serveren klar og venter på dine spørgsmål, når vi nærmer os godkendelsesdagen.