Home   2026-10-22 19:56:51

←

.Geek - Tiny Little Office is kantoorpakket waar docs alleen in hun eigen URL bestaan

Original article

Een groep privacybewuste programmeurs heeft een Office-tool gemaakt waarbij ieder document alleen als een URL bestaat. Tiny Little Office zet de tekst, berekeningen of presentaties in documenten om in een Base64-URL. Daardoor hoeft een document niet centraal te worden opgeslagen, maar blijft het wel leesbaar voor iedereen met de link.

De tool heet Tiny Little Office en is een project van de makers van AI-tool Aboard. Zij hebben de broncode van de software op GitHub gezet onder een MIT-licentie. Daar staan ook mogelijkheden de tool zelf te hosten.

Tiny Little Office is een browsertool waarmee gebruikers tekstdocumenten, spreadsheets en presentaties kunnen maken. Er is ook een agendatool en zelfs een vakantieplanner in de software aanwezig. Als gebruikers een document aanmaken, wordt alles omgezet naar platte Markdown-tekst. Dat wordt vervolgens omgezet naar Base64URL, een aangepaste versie van Base64 voor gebruik in URL's.

Dat betekent dat het volledige document in zijn eigen URL staat. Om dat te illustreren, hebben de makers een introductiedocument geschreven en opgeslagen als een lange URL.

De makers zeggen dat de bestanden niet worden opgeslagen op een server en dat iedereen met de juiste URL een bestand kan openen. Wie documenten wil delen zonder dat anderen die kunnen lezen, kan ook een wachtwoord gebruiken om ze te versleutelen. Handig voor wie eens belangrijke, maar gevoelige informatie wil delen.

Tiny Little Office

Door Tijs Hofmans

Nieuwscoördinator

Feedback • 16-10-2026 18:49 52

16-10-2026 • 18:49

52

Reacties (52)

o wow, en dat past? er zit toch een max aan je url lengte?
Dat is een vaak gehoorde opmerking, de werkelijkheid is zeer afhankelijk van de omstandigheden:
  • RFC 9110: 8kb (recommendation);
  • Apache: configureerbaar (LimitRequestLine) tot het maximum van een 32-bit integer (ong. 2GiB);
  • IIS: in theorie configureerbaar (maxUrl, maxQueryString en UrlSegmentMaxLength) obv 32-bit uint (ong. 4GiB); in de praktijk gecapped op 16MiB door de Windows http stack.
UrlSegmentMaxLength is standaard 260 op Windows, waardoor de verwarring denk ik is ontstaan.
Los van of het past; een document omzetten naar base64 geeft zo'n 30% overhead. Volgens mij kan je dus beter een Office pakket gebruiken dat je document gewoon als bestand (in een gestandaardiseerd formaat) aan je teruggeeft, al is het maar omdat je dan niet afhankelijk bent van een online dienst die morgen offline kan zijn (waarna je letterlijk niks meer kan met die link).
Hoezo afhankelijk van online dienst? Je kan het gewoon offline, lokaal of self-hosted draaien. https://github.com/aboard-io/tinylittleoffice
Hoezo afhankelijk van online dienst? Je kan het gewoon offline, lokaal of self-hosted draaien. https://github.com/aboard-io/tinylittleoffice
Dat kan, maar dit project is vijf dagen geleden gestart. Wie weet is over vijf dagen de laatste commit. Je kan het nu dan wel op je eigen server draaien maar zodra dat om een of andere reden stopt met werken zit je met een hele rits aan URLs die niets meer doen.

En ja, Word kan ook stoppen met ondersteuning voor docx bestanden maar daar zijn er zo veel van dat er altijd wel iemand op staat om een tool te maken om die te converteren naar 'het nieuwe formaat'. Dat zie ik (voorlopig) nog niet gebeuren bij Tiny Little Office.
Waarom zou het in godsnaam stoppen met werken en bovendien daarna niet opnieuw draaiende gemaakt kunnen worden?
Alles kan, maar met 130 stars op GitHub lijkt het mij dat je het vooral zelf werkend moet blijven houden.

En waarom het zou kunnen stoppen met werken? Bijna elke programmeertaal introduceert met nieuwe versies wel een aantal breaking changes. Als je de enige overgebleven ontwikkelaar bent, moet je die zelf allemaal verhelpen. Daarnaast zijn er gewoon dingen die met de tijd stoppen met werken of niet meer worden gebruikt. Leuk dat je dan een webapp hebt om via een URL bestanden te delen, maar wie zegt er dat we over 10 jaar nog met URLs werken, of met tekstverwerkers, of met browsers? Dan zal je dus over 10 jaar zelf een browser moeten ontwikkelen die gebruik kan maken van internet zoals het in 2026 was, op misschien wel een type apparaat dat we nu helemaal nog niet kennen.
Simpelweg de host die offline gaat is voldoende om het bestand onbruikbaar te maken. Ja, je kan de url aanpassen naar een nieuwe host waarop de editor plaatst, maar wil je dat liggen doen voor alle documenten. En wat met documenten die ergens gedeeld zijn in fora o.i.d.? Overal corrigeren? Dus ja, het kan hersteld worden. Maar is dat praktisch?

Het hele idee is trouwens behoorlijk dom vanuit een privacy standpunt. Zo claimen ze dat er niets opgeslagen moet worden: ok, niet bij hun op de server, maar de gebruiker zal wel de URL moeten opslaan. Dan hadden ze net zo goed een bestand kunnen teruggeven aan de gebruiker. Dat kan perfect cliënt-side. URL's komen ook in de browse-geschiedenis terecht, en bij deze aanpak betekent dat dus ook dat de inhoud van het bestand in de geschiedenis opgeslagen wordt. Iets dat je net niet zou willen als privacy je doel is. Een Word-bestand kan je ook encrypten, dus dat is ook niet echt een voordeel van deze aanpak. En bestanden werken ook offline, i.t.t. deze (of je zou een de editor op localhost moeten draaien)

Het enige voordeel van deze aanpak, dat ik zie, is als je nog een communicatiesysteem gebruikt waarbij je geen bestanden kan delen. Maar dit wordt eigenlijk niet vermeld.

Ik vind het leuk omdat het een zeker geek-gehalte heeft. Echter, als ik de github nalees krijg ik echt het gevoel dat ze niet echt nagedacht hebben over wat ze claimen.
Zozo, ga jij het overnemen dan?
zou zomaar kunnen, dat is het mooie aan open source!
In de link staat het document dus als de host offline is staat het er nog steeds in en hoef je alleen de host aan te passen in de url naar een die wel online is of lokaal draait.
Ik kan me sowieso tig betere alternatieven bedenken.
Maar het zal een niche vullen zeker?
Het is maar de vraag wat de echte meerwaarde is.
Privacy? En dat heeft libreoffice of zo niet?
De enige meerwaarde die ik kan bedenken, is dat je een document in een internetcafe kunt maken en daarna de URL afdrukken om deze daarna bij het volgende internetcafe weer volledig in te tikken zodat je verder kunt werken aan je document zonder dat iemand anders het in handen krijgt.

Alleen een beetje jammer dat de URL-hash door gebruik van base64 zo'n 30% langer is dan het originele document...
Apache en IIS hebben hier niks mee te maken. Het document komt in het hash gedeelte, wat niet naar servers wordt verzonden.

Chrome kan daar 2 MB in kwijt, en Firefox 1 MB.
Als je hem post naar een server wel. Zolang het met js in de browser is volgens mij niet.
Jawel, ergens tussen de 30k en 60k chars afhankelijk van de browser. :P
Ik lees ergens tussen de 64k en 2Mb. Nog steeds vrij lang als je markdown schrijft. Als je echter opmaak en plaatjes gaat toestaan is het snel voorbij :)
Tiny Little Office heeft hier rekening mee gehouden in hun applicatie(s). Wanneer je aan het werk bent in bijvoorbeeld een Document of Spreadsheet of wat voor document dan ook, wordt rechtsboven een cirkeltje weergegeven hoe groot je document kan worden. Wanneer je daarop klikt wordt er een tabel weergegeven waarin de "Max Link Sizes" worden weergegeven (kreeg de tabel hier niet netjes weergegeven, sorry, deze tabel komt uit de Word Processor):
Max Link Sizes

This link: 39 characters, 39 bytes Where Limit Fits?

a text message 160 characters Yes, 121 left

a small NFC sticker 504 bytes Yes, 465 left

an NFC sticker 888 bytes Yes, 849 left

a Discord message 2,000 characters Yes, 1,961 left

older browsers 2,048 characters Yes, 2,009 left

a QR code 2,953 bytes Yes, 2,914 left

a link in Google Docs 4,096 characters Yes, 4,057 left

a Telegram message 4,096 characters Yes, 4,057 left

X 4,096 characters Yes, counts as 23 of 280

a short link 12,272 bytes Yes, 12,233 left

Mastodon None published Yes, counts as 23 of 500

Bluesky None published Yes, counts as 30 of 300

Firefox 1,048,576 characters Yes, 1,048,537 left

Chrome and Edge 2,097,152 characters Yes, 2,097,113 left

Safari None published Yes
Vraag me tegelijkertijd af of ze met bijv. tekst-content geen GZIP-compressie of vergelijkbaar kunnen gebruiken voor ze het omzetten naar Base64. Tekst is over het algemeen goed te comprimeren.
Misschien eerst compressie en dan base64?
Zo der compressie zie ik dat idd niet goed komen. En het zal idd zeker zijn lieten hebben. Ik zie het niet gebeuren met 20MB spreadsheets. ;)
Moet je er wel vanuit gaan dat de server niks logt? Want ik neem aan dat de server gewoon logt met welke URL verbinding gemaakt wordt, ook al staat het document dan niet op de server
Als je kijkt naar waar een URL uit opgebouwd is, dan wordt inderdaad een groot deel naar de server gestuurd om te verwerken. Echter wordt het fragment niet doorgestuurd.

In dit geval is dat dus de applicatie die gestart moet worden en de content die weergegeven moet worden. Die gaan dus niet mee naar de server. Daarmee kunnen ze terecht aangeven dat ze niets opslaan, want ze krijgen het dus uberhaupt niet eens. Een prima implementatie dus.
Dan is het wel grappig ja!
Ik snap sowieso de stelling niet dat het bestand alleen bestaat in de url.

Immers zal niemand die url uit het hoofd weten. En omdat het bestand in de url zit, is het opslaan van de url toch exact hetzelfde als het opslaan van welk enig ander bestand?


Of misschien ik hier nu iets?
Ik volg het ook helemaal niet. Wat is het verschil tussen deze url (die blijkbaar niet naar een online-bestand verwijst) en een tekst met een soort geavanceerde Markdown die je kunt kopiëren en plakken? En wat is de toegevoegde waarde? Tenzij het erom gaat dat de software die je het document laat bewerken en weergeven wel op de server staat. Dat is een URL een makkelijke manier om een bestand van je computer te laten openen door de software op de server.
De makers zeggen dat de bestanden niet worden opgeslagen
Waar worden die URL's dan opgeslagen? In de aether of zo?
  • Overal waar jij het besluit op te slaan, bv. in een bladwijzer;
  • in je browsergeschiedenis en
  • als je het kopieert, dan ook in je klembord(geschiedenis).
De tekst zit in die URL, de editor leest dat uit. Er is geen serveropslag voor nodig, er is zelfs geen lokale opslag nodig, want het zit in de URL.

Het is vergelijkbaar met Google Translate, alleen weten we dat Google alles ook opslaat, ze maken het je alleen gemakkelijk om vertalingen te delen of via je browsergeschiedenis terug te vinden. Bovendien heeft Google Translate een karakterlimiet van 5000 tekens, dat is met deze dienst niet het geval, dus de limiet is heel hoog en gebaseerd op browserlimieten voor data URLs (heel groot).

[Reactie gewijzigd door Blizz op 16 oktober 2026 19:04]

De url staat nog steeds op de server, dus wat schiet je hier nu mee op.
Tja, de documentatie beweert dat het niet op de server wordt opgeslagen. Dus het zal aan eventuele logging(sduur) liggen, maar de suite zelf doet niet aan opslag. Bovendien kun je het zelf hosten.

[Reactie gewijzigd door Blizz op 16 oktober 2026 19:08]

Je bedoelt in de logfile van de http server?
Nee dat staat iets op de server, de url is de data waarmee het document wordt gegenereerd op het moment dat jij die url opent. Er is geen reden om de url op te slaan.
Alles na een # wordt client side verwerkt en door de browser niet naar de server gestuurd. Dus bij de url https://tinylittleoffice.com/#/v1/write/yQ7LIBVYYg60wNNA1NFNQNkSzGSwcYmhhZWAUBdbsAsxqwAwHys4lwPCDF~lcAA wordt het stuk #/v1/write/yQ7LIBVYYg60wNNA1NFNQNkSzGSwcYmhhZWAUBdbsAsxqwAwHys4lwPCDF~lcAA niet naar de server gestuurd en dus ook niet gelogd.
Niet bij hun in ieder geval. De URL bevat je volledige document, de lezer haalt de data direct daar uit.

In het geval van dit nieuwsartikel staan desbetreffende documenten dus in dit tweakers-artikel opgeslagen.
Je maakt gewoon een bestandje op je PC (onder Windows met de 'extensie' .URL) en daar schrijf je de URL in (in ASCII tekens). Bijvoorbeeld "Tiny Little Office is een kantoorpakket waar docs alleen in hun eigen URL bestaan.URL".
Neemt die URL dan niet even veel plaats in als het origineel bestand? En als je pc crasht ben je het even goed kwijt want je kan het zo 1-2-3 niet venbuilen leren die URL
Gewoon encoded URL, die sla je op in een .txt file 😂
Dan moet een bedrijf haar backup strategie ook aanpassen. De desktop (waar veel mensen snelkoppelingen naar documenten plaatsen en nu dus de volwaardige documenten) en alle andere locaties waar men van alles neerzet. :-(
Ik heb hier en daar wat bedenkingen.
Maar vooral... ik vind dit een hilarish idee.
Ik heb mijn eigen 'infra' dus in de plaats van word docs sturen lijkt het me leuk om dit als sharing formaat te gebruiken. Meer voor de grap van wat anders.
Basically is het een leuke manier om base64 encoded markdown the sharen.
Is het al 1 april?

Nee serieus, wat is hier privacybewust aan? Als je er geen wachtwoord op zet dan kan iedereen die de url kan onderscheppen het document lezen.

En over onderscheppen gesproken, als je zelf URL’s logt op je corporate proxyserver dan zul je het merken als er iemand met dat pakketje aan de slag gaat. Ik weet niet hoe vaak die documenten opslaat… ehhh de URL aanpast, maar dat kan nog wel eens een dingetje worden. Alvast een tip voor de gebruikers: voordat je er ook maar iets gevoeligs in zet, eerst je wachtwoord instellen!
als je zelf URL’s logt op je corporate proxyserver dan zul je het merken als er iemand met dat pakketje aan de slag gaat
Dat impliceert dan weer wel dat er aan decryptie en encryptie gedaan wordt op de proxy. Op zich is dat niet onmogelijk, maar bij het encrypten is wel een nieuwe versleuteling met bijbehorend certificaat noodzakelijk. Hiervoor is dan ook weer het bijbehorende root-certificaat nodig dat op de clientcomputer geïnstalleerd moet worden en dat is dan weer zichtbaar voor de gebruiker.

Als gebruiker zou ik gelijk achterdochtig worden als een versleutelde verbinding op die manier onderschept wordt.

Overigens zou ik voor gevoelige dat altijd wel een wachtwoord gebruiken, niet alleen in dit voorbeeld. In dit concrete voorbeeld is er altijd het risico dat er ergens een poging gedaan wordt om van https naar http te downgraden en dan zit je weer met een veiligheidslek.

* Little Penguin vindt deze URL-opslag wel grappig en dan vooral dat. Voor echte opslag, zelfs al is het op een zelfgehoste server is het natuurlijk niet een oplossing die op lange termijn voor duurzame opslag zorgt...
Bij veel versleutelde verbindingen is de URL juist niet versleuteld. Het kan tegenwoordig wel, maar dat wordt nog niet breed ingezet.

Bij een reguliere versleutelde verbinding voert de webbrowser een DNS query uit om het ip adres te achterhalen. Naar dat ip adres wordt een beveiligde verbinding opgezet. Als de URL versleuteld zou zijn dan kan de server niet het juiste certificaat van de juiste vhost opsturen. Want hij weet simpelweg niet welke. En ja, daar is een oplossing voor maar die ben ik nog niet heel vaak tegen gekomen. (Al moet ik wel zeggen dat ik er eigenlijk ook niet heel erg op let).
De URL bestaat uit meerdere delen, in dit geval zijn de fragment-identifier (waar het document dus in opgeslagen is) en de dns-name belangrijk.

Voor versleutelde verbindingen is de dns-name (hostname) inderdaad niet versleuteld, alleen zit daar geen gevoelige informatie in - alleen dat het van little office is. De rest van de URL, waaronder ook de fragment-identifier is wel versleuteld.
Maaruh, let wel: elke keer dat je je document aanpast, pas je dus ook de URL aan.

Er is geen bestand, de URL zelf is de data.
Ja, dat is lekker.

Ik deel regelmatig bestanden via Sharepoint "hier de link, dan kun je deze ook aanpassen.". Dat gaat dus niet werken, want alle wijzigingen blijven dus enkel lokaal en worden niet gedeeld.
Dus dan moet je weer een bijgewerkte URL versturen. En na een paar keer, heb je dus meerdere URL's in je mails staan. Pak je de verkeerde mail/link, krijg je weer problemen dat je dingen mist en moet je dus weer vergelijken en bijwerken. Helemaal erg als je een keer vergeet om je nieuwe link op te slaan (Ms Office heeft auto-save, niet zonder reden).

Dus leuk als demo. Maar niet voor serieus gebruik.
Zeker handig voor die belangrijke, maar inderdaad zeer gevoelige informatie! :+
Grappig idee, maar ziet eruit alsof het in een middag in elkaar gevibecode is.

Vooral de zin "That one fact is the whole design" in het intro document is precies hoe Ai dingen verwoordt 😅
Is het waarschijnlijk ook:

"A user you’ve blocked has previously contributed to this repository.

claude"
Interresant:
When tinylittleoffice.com is down, the same tag runs on GitHub Pages at https://aboard-io.github.io/tinylittleoffice/ (the mirror): put that before the <app>/#… of a link and it opens there.
Als ik het goed lees en snap, bestaat heel die app eigenlijk bijna alleen maar in je browser en kan hij dus "op" elke static-file-host draaien en werken. Eigenlijk jammer dat ze er ook een url-verkorten en statistieken aan gekoppeld hebben waardoor ze server-logica nodig hebben.

Wel een leuke manier om stukken tekst en diagrammen te delen op plekken waar je normaal alleen tekst kan delen en geen files.

Om te kunnen reageren moet je ingelogd zijn