💾 Archived View for gemini.circumlunar.space › docs › nl › best-practices.gmi captured on 2022-06-11 at 21:24:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Dit is een vertaling van het Gemini "best practices" document, zoals deze is op 2021-02-28.
Stuur Nederlandse vragen over dit document of opmerkingen en suggesties voor deze vertaling naar de vertaler, pjvm <pjvm742 _apestaartje_ disroot _punt_ org>.
Dit document beschrijft "best practices": bepaalde conventies en stukjes advies voor het implementeren en gebruiken van het Gemini-protocol die, hoewel niet vereist door de protocolspecificatie, algemeen als goede ideeën beschouwd worden. Als je Gemini-software schrijft of een Gemini-site maakt, zou je er goed aan doen dit advies te volgen tenzij je goede redenen hebt om het niet te doen.
Gemini-servers moeten clients het MIME-type meedelen van bestanden die ze aanleveren. De makkelijkste manier voor servers om achter het MIME-type te komen is met de extensie van de bestandsnaam. De betekenis van extensies is grotendeels goed gestandaardiseerd (en unix-systemen hebben vaak een /etc/mime.types dat er vol mee staat), maar de vraag blijft hoe servers bestanden van het door Gemini gedefinieerde type text/gemini moeten herkennen.
Huidige Gemini-servers lijken hier .gmi of .gemini voor te gebruiken en nieuwe servers wordt sterk aangeraden een van deze of beide opties te ondersteunen in plaats van een nieuwe te bedenken.
De conventie van webbrowsers wordt overgenomen om bij een verzoek dat correspondeert met een map op de servers bestandssysteem, als er in die map een bestand genaamd index.gmi of index.gemini bestaat, dat bestand aan te leveren.
Gemini-servers informeren clients niet over de grootte van het bestand dat ze sturen, wat het moeilijk kan maken om het te detecteren wanneer de verbinding voortijdig is afgebroken door een serverfout. Dit risico neemt toe met de grootte van het bestand.
Gemini ondersteunt ook geen datacompressie van grote bestanden of controlegetallen voor het detecteren van datacorruptie, een risico dat ook toeneemt met de grootte van het bestand.
Om al deze redenen is Gemini niet erg geschikt voor het overbrengen van "erg grote" bestanden. Wat precies telt als "erg groot" hangt deels af van de snelheid en betrouwbaarheid van de betrokken internetverbindingen en het geduld van de gebruikers. Als vuistregel kun je bestanden groter dan 100MiB maar beter op een andere manier beschikbaar stellen.
Omdat text/gemini links toestaat naar elk ander protocol dat URLs gebruikt, is het natuurlijk mogelijk om vanuit een Gemini-document te linken naar een groot bestand op HTTPS, BitTorrent, IPFS of wat je ook maar blij maakt.
Gemini ondersteunt alle tekst-encoderingen met de "charset"-parameter van text/*MIME-typen. Dit maakt het mogelijk om "legacy" (gedateerde) tekst in obscure regionale encoderingen bechikbaar te stellen.
Gebruik voor nieuwe dingen alsje-, alsje-, alsjeblieft gewoon UTF-8. De Gemini-specificatie verplicht clients om met UTF-8 tekst om te kunnen gaan. Voor andere encoderingen mag de client het zelf weten, en is het niet gegarandeerd dat het correct weergegeven wordt. Het gebruik van UTF-8 zorgt voor een zo toegankelijk mogelijke site en zorgt ervoor dat simpele, alleen UTF-8 ondersteunende clients zo bruikbaar mogelijk zijn.
Redirects zijn voornamelijk in Gemini opgenomen zodat herorganisatie en migratie van sites niet tot kapotte links hoeft te leiden. Een grote, onderling verbonden ruimte van documenten wordt zonder iets als redirects snel "broos".
Redirects zijn echter, in het algemeen, nare dingen. Ze maken het protocol minder transparant, maken het moeilijker om een geïnformeerde keuze te maken om een link te volgen en ze kunnen informatie over de online activiteit van mensen lekken naar derde partijen. Ze zijn in Gemini minder slecht dan in HTTP (geen cookies, referer-headers enz.), maar ze blijven op z'n best een noodzakelijk kwaad.
Gebruik redirects dus alsjeblieft niet zomaar! Dingen als URL-verkorters zijn bijna totaal waardeloos. In het algemeen, denk heel goed na voordat je redirects gebruik voor iets anders dan kapotte links voorkomen.
Clients kunnen de gebruiker vragen of ze een redirect moeten volgen, of dat automatisch doen. Als je een client schrijft die ze automatisch volgt, wees je dan bewust van de volgende problemen.
Verkeerd ingestelde of kwaadwillige Gemini-servers kunnen redirects geven die een naïeve client vasthouden in een oneindige lus of anders een zeer lange keten laten doorvolgen. Robuuste clients moeten slim genoeg zijn om dit te detecteren en daarnaar te handelen. De simpelste implementatie is om te weigeren meer dan N opeenvolgende redirects te volgen. Het wordt aanbevolen om N niet hoger dan 5 te maken. Dit is in lijn met de oorspronkelijke aanbeveling voor HTTP (zie RFC-2068).
Redirects naar URLs op andere protocollen zijn mogelijk met Gemini, maar worden sterk afgeraden. Verkeerd ingestelde of kwaadwillige servers zullen deze echter altijd kunnen geven, dus goed geschreven clients moeten ze kunnen detecteren en ernaar handelen.
Het wordt sterk aanbevolen dat clients die anders redirects automatisch volgen de gebruiker wèl om expliciete toestemming vragen bij een redirect naar niet-TLS-versleutelde protocollen als HTTP en Gopher, aangenomen dat de client die protocollen ook ondersteunt. Dit om onbedoelde schakelingen naar een onversleutelde verbinding te vermijden.
TLS 1.2 wordt met tegenzin toegelaten in Gemini, ookal is TLS 1.3 drastisch simpeler en zijn veel onveilige versleutelingsprimitieven verwijderd. De reden is dat alleen OpenSSL nu TLS 1.3 goed lijkt te ondersteunen, dus TLS 1.3 of hoger vereisen zou het gebruik van libraries als LibreSSL of BearSSL ontmoedigen, die voor de rest in veel aspecten beter aan te bevelen zijn dan OpenSSL.
Client- en server-auteurs die ervoor kiezen om TLS 1.2 te ondersteunen zouden het beste de toegestane ciphersuites beperken tot die die vergelijkbare beveiliging bieden tot TLS 1.3 . Speicifiek zou de software het beste: