2025-12-24 23:56:16
We staan aan de vooravond van een nieuwe technologische golf. Zo. Ik heb gesproken.
AI-tools maken het nu al mogelijk om zonder programmeerkennis eigen persoonlijke software te bouwen. We zijn nog niet in het stadium dat er productieklare, schaalbare apps ontstaan. Maar een app die direct een probleem oplost voor een individuele gebruiker? Of die iets mogelijk maakt wat voorheen niet kon? Daar staan we nu.
Het roept vragen op die we eerder moesten stellen. Wat betekent het als miljoenen mensen hun eigen apps kunnen maken? Wie bouwt de infrastructuur om deze veilig te delen? Hoe voorkomen we dat dit nieuwe ecosysteem wordt opgeslokt door dezelfde platforms die het open web hebben opgeslokt de afgelopen 15 jaar? En hoe zit het met de schaduwkanten van AI: de privacy-implicaties, het dataverbruik voor training, de ethische dilemma’s, het gebrek aan diversiteit in de trainingsdata, de milieubelasting van datacenters, de kosten die niet voor iedereen gelijk zijn?
Die vragen beheersen nu het gesprek en dat is logisch. Want als we iets hebben geleerd van de afgelopen twintig jaar BigTech, dan is het dat ze de regels schrijven tijdens de verspreiding van technologie. Dus is het goed dat al die vragen er nu zijn. Tegelijk bekijken we waar de kansen liggen.
Afgelopen vrijdag 19 december liet Martijn zien wat hij kon maken zonder enige programmeerkennis. Zijn ThetaOS spreekt tot de verbeelding, maar nog belangrijker dan de app zijn de checks and balances die hij onder water bouwt en beheert. Hier publiceert hij veel over en we hebben er geregeld gesprekken over. We steken elkaar aan met ideeën, helpen elkaar vooruit met inzichten en ik kijk graag over zijn schouder mee wat hij doet. 
Zijn verhaal paste perfect bij de workshop van die ochtend. Voor een groep van 25 enthousiaste niet-programmeurs ging een wereld open met Claude Code. Hier zag ik met eigen ogen de technische barrière instorten die decennia standhield. Martijn schrijft over de scheur in de muur van de App Stores, ik zag hem ontstaan in dat zaaltje.
In 2 uur zag ik een persoonlijke wijndatabase verschijnen, een privé mobiele klantenkaart app die geen data slurpt, een app om je tuin op orde te houden door het jaar heen, een Zweedse taal app, een Spaanse taal app (want beiden hebben een hekel aan de enshittification van Duolingo), de opzet naar een eigen takenmanager, een comicstrip creator. Ik zag de rest van de dag een andere deelnemer constant bedenken wat ze nu allemaal kon maken. Welke Final Boss krachten nu unlocked waren… En een dag later kreeg ik een bericht dat een andere deelnemer zijn persoonlijke CRM systeem nu op orde had.
“Ik ben bloody blown away met wat allemaal mogelijk is”, is slechts één van de reviews die ik via mail, Signal en in gesprekken kreeg.
30 januari kun je het zelf ervaren als ik de workshop nog een keer geef. Natuurlijk kun je me altijd mailen of DM’en voor een in-company startersessie Conversational-Driven Development.
Hoe chaotisch het web kan zijn: haar geschiedenis kent een patroon. Telkens wanneer een technische drempel valt, ontstaat een explosie van creativiteit van onderop.
De eerste golf: publicatie (1999-2005)
Begin 1999 waren er 23 bekende weblogs. Rebecca Blood, pionier en historicus van de blogcultuur, documenteerde wat er toen gebeurde. De belofte van het web was dat iedereen kon publiceren. De werkelijkheid was anders: alleen mensen die HTML beheersten konden hun stem laten horen. Toen lanceerden o.a. Pitas en Blogger. Plotseling konden mensen zonder technische kennis een eigen plek op het web claimen. Ik kan het weten, ik was erbij. Ik heb er zelfs nog een boek over geschreven. Binnen een paar maanden waren er honderden blogs. Binnen een paar jaar miljoenen. En zo ontstond een hele cultuur: de blogosphere, met eigen zoekmachines (Technorati), eigen conventies voor exploratie en ontdekking (trackbacks, blogrolls), eigen sterren en schandalen. En vooruit, eigen awards…
Het belangrijkste was dat de technologie om iets te publiceren op het web ineens voor iedereen beschikbaar was. Naast blogs kregen ook persoonlijke webpagina’s een enorme boost, met hun eigen beeldtaal, los van wat we kenden van magazines, TV en kranten.
De tweede golf: netwerk (2005-2012)
Je blog was een uitzendmedium. Jesse James Garrett noemde ze de Pirate Radio Stations of the web. Het zijn persoonlijke platformen waar je als individu je mening kunt geven. Je publiceerde, hopend dat iemand het zou vinden. Social media draaide dit om: het netwerk kwam eerst. Facebook, Twitter, en in Nederland Hyves maakten zichzelf de kern van de verbindingen. Je hoefde niet eens te publiceren om deel te nemen. Als blogger waren we nog producent. De sociale kanalen maakten weer consumenten van ons. Ondanks de kleine interacties van likes, shares en comments, écht iets maken was er nog maar weinig bij. Het werd nog erger. Algoritmes optimaliseerden op engagement, die veelal op woede en polarisatie is gericht, de aandacht op het platform werd verkocht aan de hoogste bieder en onze data wordt gebruikt om ons constant te tracken. En om nu LLM’s mee te voeden. Wat me op de derde golf brengt.
De derde golf: creatie (2008-nu)
Parallel aan de opkomst van social media begon een andere revolutie. De iPhone lanceerde in 2007, de App Store opende in 2008. Plotseling kon software op een apparaat in je broekzak draaien. Maar de technische drempel bleef hoog en Apple voegde daar nog een laag aan toe: Elke app kende een review-proces en een commissie van 30% op elke transactie. Martijn beschrijft in zijn stuk uitgebreid hoe we door AI code-assistenten die technische muur laten instorten. Met Claude Code maak je je eigen applicaties. Dat kunnen webapplicaties zijn, of volwaardige iPhone apps. Android zal net zo goed mogelijk zijn, maar valt buiten mijn kennis van dat ecosysteem. Martijn, ikzelf, deelnemers aan de workshops en Digitale Fitheid Meetups, we beschrijven wat we willen en samen met de software werken we naar een eindresultaat. En zo ontstaan er miljoenen niche-apps, gedeeld buiten de App Store. Die zijn niet bedoeld voor massamarkten, maar voor persoonlijk en wellicht klein-gemeenschappelijk gebruik.
| Golf | Periode | Barrière die viel | Wat het mogelijk maakte | Wat ontstond |
|---|---|---|---|---|
| Publicatie | 1999-2005 | HTML-kennis | Blogger, WordPress | Blogosphere |
| Netwerk | 2005-2012 | Bereik, verbinding | Facebook, Twitter, Hyves | Social web |
| Creatie | 2008-nu | Programmeerkennis | App Store → AI-tools | ? |
Het vraagteken in die laatste cel maakt het interessant. Wat zal onstaan?
Om te begrijpen wat er kan ontstaan, moeten we eerst begrijpen wat we kwijtraakten.
In december 2012 schreef technologie-commentator Anil Dash een essay dat nog steeds nagalmt: “The Web We Lost.” Hij beschreef hoe de tech-industrie de opkomst van netwerken behandelde als pure winst voor gebruikers. Zelden werd gesproken over wat we onderweg eigenlijk verloren. Dash herinnerde zich een web waar foto’s op Flickr werden geüpload met tags die machines én mensen konden lezen. Waar je met Technorati de blogosphere in real-time kon doorzoeken. Waar sites naar elkaar linkten en die links meer betekenis hadden dan om SEO redenen. Afgelopen vrijdag hadden Ton Zijlstra en ik een nostalgisch gesprek over del.icio.us, de beste sociale bookmarktool die nooit tot volle wasdom kon komen. Maar waar je elkaar volgde op basis van de linkverzameling en tags.
Maar het echte verlies was subtieler: de persoonlijke homepage. In de jaren negentig had je een homepage. Een digitale plek die jou representeerde, vormgegeven naar jouw smaak, met jouw inhoud, onder jouw controle. Het was rommelig en amateuristisch en prachtig. Elke homepage was anders, want elke maker was anders. Sociale platforms reduceerden dit tot een profiel. Dezelfde MySpace, Facebook, Hyves of Twitter template voor iedereen. Dezelfde mogelijkheden, dezelfde beperkingen. Onze identiteit werd een invulformulier. Nog zonder captcha om verkeerslichten en pinguins te herkennen.
Wat Martijn beschrijft is niet zomaar een technische ontwikkeling. Hij ziet dat zelf ook. Het is de mogelijke terugkeer van iets dat we verloren waanden, maar met een cruciale upgrade. Een homepage was statisch. Een blog was chronologisch. Een app is functioneel. AI-gegenereerde apps zijn “persoonlijke homepages” die iets doen. Ze lossen een probleem op dat jij hebt. Ze werken op de manier die jij prettig vindt. Ze delen geen data met adverteerders. Ze worden niet slechter omdat een platform besluit meer geld te verdienen.
Martijn voorspelt miljoenen niche-apps, gedeeld buiten de App Store. Dit is precies wat Harvard-professor Yochai Benkler in 2006 beschreef als “commons-based peer production”: gedecentraliseerd, collaborative, niet gericht op eigendom of winst. Het verschil met twintig jaar geleden: de tools bestonden nog niet om dit werkelijk op grote schaal te realiseren. Nu wel.
De academische literatuur over online platforms is de afgelopen twintig jaar geëxplodeerd. De conclusies zijn ontnuchterend en dat zal je niets verbazen. Mensen als Shoshana Zuboff(Surveillance Capitalism), Nick Srnicek(Platform Capitalism) en Cory Doctorow (Enshittification) maken duidelijk dat het social web er niet lekker aan toe is. Het werkt alleen bij afhankelijkheid van het platform. Een zelfgebouwde app is minder afhankelijk. De afhankelijkheid is er tot op zekere hoogte, want het is met AI gebouwd. Maar je zit meer aan de knoppen wat je idee moet doen en kunnen. En vooral wat het niet moet doen. Geen algehele platformbeslissingen. Geen advertenties. Geen API-toegang die plotseling wordt afgesloten. Geen 30% commissie. Geen willekeurige afwijzing door reviewers.
Ik was betrokken bij de IndieWeb-beweging in Nederland en ervaar constant wat het effect kan zijn als je echt autonoom bent. Als alles in je eigen bezit is. Het geeft een digitale vrijheid die moeilijk te beschrijven is.
Technologie alleen is echter niet genoeg. De University of Toronto concludeerde in hun onderzoek naar het Indieweb: “Voor een beweging die individuele autonomie benadrukt, zijn IndieWeb’s evenementen en community-netwerken de drijvende kracht achter haar levensduur.”
De blogosphere stortte niet in door technische beperkingen. Technorati indexeerde 133 miljoen blogs. Maar 94% verdween. Niet omdat bloggen ineens moeilijker werd, maar omdat de sociale infrastructuur verschoof naar platforms die engagement optimaliseerden boven betekenis.
Als de AI-codetools werkelijk een nieuwe fase van digitale democratisering inluiden, dan staan we voor vragen die we eerder hadden moeten stellen. De vragen die we vergaten bij de komst van blogs en sociale netwerken.
Wat is het RSS-protocol voor apps? RSS maakte het mogelijk om blogs te volgen zonder een platform als tussenpersoon. Wat is het equivalent voor niche-apps? Hoe vind je de app die iemand in Australië bouwde voor precies jouw probleem? Wie bouwt de Technorati voor AI-gegenereerde software? Misschien ligt een deel van het antwoord in protocollen zoals Nostr: open standaarden die discovery en connectie mogelijk maken zonder een centrale poortwachter.
Wat voorkomt dat dit ook enshittified? Platforms slokten de blogosphere op. Influencers en social creators zijn afhankelijk van ondoorgrondelijke algoritmes. Welke structuren voorkomen dat deze app-renaissance hetzelfde lot ondergaat?
Wie bouwt de commons? Martijn voorspelt platforms voor het delen van broncode, “GitHub meets App Store.” Maar wie bouwt dit? En volgens welk model? Is het eigendom van de community of van het platform?
Hoe gaan we om met de schaduwkanten? AI-tools zijn niet neutraal. Ze zijn getraind op data waarvan de herkomst niet altijd helder is. Ze draaien op datacenters die te veel water en energie verbruiken. Ze kosten geld dat niet voor iedereen gelijk beschikbaar is. Ze roepen vragen op over privacy, over eigenaarschap van gegenereerde code, over de arbeidsomstandigheden van mensen die trainingsdata labelen. We kunnen niet doen alsof deze vragen niet bestaan. De vraag is hoe we een dialoog voeren die zowel de mogelijkheden erkent als de kosten eerlijk weegt.
Wat is de nieuwe digitale geletterdheid? Als software-creatie een basale vaardigheid wordt, wat betekent dit dan voor onderwijs? Voor werk? Voor de definitie van wat het betekent om digitaal vaardig te zijn?
En de belangrijkste vraag: De homepage verdween niet omdat hij technisch onmogelijk werd. Hij verdween omdat platforms makkelijker waren en meer bereik boden. De technische barrière voor apps is nu weg. Maar de sociale en economische krachten die ons naar platforms duwden bestaan nog steeds. Wat is er dit keer anders?
Misschien is het antwoord: niets is anders. Misschien worden AI-gegenereerde apps een nieuwe categorie die de grote platforms zullen absorberen en monetizen. Want dat is nu eenmaal zoals de BigTech werkt: Embrace, extend en extinguish.
Maar ik blijf die naïeve hoop houden. Misschien is er wel iets veranderd. Want we moeten toch íets hebben geleerd van de afgelopen twintig jaar aan Big Tech platform dominantie? We weten nu wat we verliezen als we bouwen op geleend land, zoals Twitter. We ondervinden de enshittification aan den lijve. We zien hoe ze onze data opslurpen, verzamelen, bundelen en verkopen aan bedrijven en overheden. Hoe ze onze digitale identiteit reduceren tot een profiel in andermans template.
Toen we in 2000 lekker zaten te bloggen, wisten we niet wat we hadden. Tot het weg was. Nu weten we wel beter. Toch? De vraag is of die kennis genoeg is om het dit keer anders te doen. En of we bereid zijn om de moeilijke gesprekken te voeren over hoe we nieuwe technologie inzetten op een manier die individuele makers helpt, zonder de wereld naar de knoppen te helpen.
Leuk, dat historisch perspectief, maar wat nu? Wel, je kunt er onderdeel van uitmaken. Het zelf meemaken! 30 januari geef ik de Claude Code Open workshop nog een keer. Gratis en voor niks bij Wonders of Work in Utrecht. Wil je met je team of bedrijf proeven aan deze nieuwe revolutie? Dan is een in-company workshop altijd mogelijk. Mail me!
2025-12-18 22:16:40
Mijn Claude Code AI app is heus geen zoemende server in Silicon Valley! Het zit echt ergens in een kantoor mijn code te debuggen. Of in elk geval, dat probeert het. Want het maakte zelf een domme fout. Toen ik er naar vroeg kreeg ik uitgebreide excuses. Waaronder:
Het echte probleem zat tussen stoel en toetsenbord - ik blokkeerde de server met mijn eigen test commands. Een maand geleden werkte alles omdat je toen geen debug commands had draaien.
Zou dat nou die Soul zijn bij Anthropic waar zoveel om te doen is?
Ik moet soms echt wel een beetje lachen om Claude. Ondanks dat het een Algoritmisch Inschattingsmodel is!
2025-12-18 20:58:29
Ik zat begin deze middag met een probleem. Ik wilde Claude Code een agent laten maken die ISO tests (dank je wel Monique) op mijn code kon doen. Zelfstandig, zonder mij te veel lastig te vallen. En natuurlijk met feedback. Maar wat Claude Code gaf was een skill, maar dat was volgens mij niet wat ik nodig had.
Dat bracht me op het agents versus skills concept wat ik nog steeds niet goed begrijp en volgens mij andere mensen ook niet: agents en skills zien er misschien op het oppervlak hetzelfde uit (allebei mappen met instructies), maar ze zijn totaal anders. Of eigenlijk liggen ze heel dicht bij elkaar in mijn hoofd. Een agent heeft bepaalde skills. Een tekstschrijver kan zelfstandig teksten schrijven en heeft de competenties om dat te doen. Maar waarom zijn die twee dan gescheiden? Het blijkt dus, het gaat niet zozeer om techniek als om je rol:
En de keuze bepaalt eigenlijk hoe je Claude Code gaat inzetten.
Skills zijn instructiehandboeken. Agents zijn zelfstandige specialisten.
Een Skill zit in een mapje met een SKILL.md bestand met richtlijnen, voorbeelden en referentiematerialen. Wanneer jij Claude iets vraagt, scant hij of een Skill relevant is. Zo ja, dan laadt hij ze in. Hij leest de instructies en volgt ze op. Ik wacht er ondertussen op totdat Claude klaar is.
Een Agent is anders. Het zijn Mini-Claude’s met hun eigen system prompt, toolset en afzonderlijke context window van 200.000 tokens. Agents zijn eigenlijk een team van experts: ze hebben elk hun eigen rol en functie. Ze gaan zelfstandig aan de slag, kunnen fouten herkennen, teruggaan, opnieuw proberen en itereren. Ze rapporteren terug met resultaten, niet met “ik ben klaar met je instructies volgen”.
Praktisch gesteld:
Een Skill zegt: “Hier staan de richtlijnen voor branding, volg ze netjes.”
Een Agent zegt: “Jij bent de design expert. Ga zelfstandig controleren of deze site aan onze brand guidelines voldoet. Rapporteer terug wat er mis is en wat je zou aanpassen.”
Dit is het kernverschil. Maar nu wordt het interessant, want ik moet een keuze maken. En die keuze bepaalt eigenlijk hoe het werk gaat verlopen.
Ik merkte dat op het moment dat ik Claude Code vraag om bijvoorbeeld: “Controleer mijn code op performance issues.” Claude Code kan kiezen: Skill of Agent?
Als Claude een Skill maakt, laadt die in mijn huidige window. Claude leest de performance-checklist, volgt stap voor stap wat ik heb geschreven en geeft feedback. Het is snel, synchroon, en ik ben niet afhankelijk van agents die hun eigen gang gaan.
Als Claude een Agent maakt, maak ik eigenlijk een specialist aan die onafhankelijk werkt. Die Agent gaat mijn code analyseren, kan teruggaan en dieper graven, kan voorstellen testen, kan itereren. Ik hoef niet te wachten. Ik laat de Agent los en ga zelf verder met iets anders. De Agent rapporteert later.
Hier zit de echte beslissing. Het gaat niet zozeer om de techniek als om de werkwijze die ik prettig vind met AI-modellen. En dat is iets waar ik ook nog steeds aan moet wennen: wanneer wil ik nou eigenlijk een agent gebruiken en wanneer wil ik een skill gebruiken? Ik weet dat nog steeds niet heel goed. Maar langzaam zie ik wel een patroon.
Agents zijn voor exploratie en verbetering. Je zet ze in als je:
Praktisch voorbeeld: ik heb een codebase met 50 bestanden en ik wil dat Claude die doorloopt, security issues vindt, patches voorstelt en die test. Ik kies dan voor een agent, want die gaat zelfstandig aan de slag. Ik kan ondertussen iets anders doen.
Skills zijn voor regels en standaarden. Je zet ze in als je:
Praktisch voorbeeld: ik heb brand guidelines geschreven en ik wil dat Claude die altijd toepast bij documenten. Ik kies dan voor een skill. Claude leert het, past het toe als het nodig is.
Dus ik wilde een ISO-test agent. Claude Code maakte een Skill. Ik zat even te denken: kan ik niet gewoon een Agent maken die die ISO-Skill inlaadt?
Een agent die een Skill inlaadt is dubbel werk. Je agent zou in feite zeggen: “Wacht, laat me eerst deze handleiding lezen” en dan de instructies volgen. Dat kost dus extra tokens voor iets wat eigenlijk niet nodig is. Dan kan ik net zo goed zelf dat handboek lezen en het werk zelf doen. “Laat maar, ik doe het zelf wel” - en dan ben je sneller klaar.
Nou, er is één scenario waar het wel voordelig is. Niet voor dezelfde taak, maar complementair.
Stel je de Ticket-beheerder agent voor. Die Agent doet iets groots: aanvragen verwerken, prioriteiten stellen, bepalen wie het gaat oppakken. En incidenteel heeft die Agent iets nodig wat in een Skill staat. Bijvoorbeeld: “Zorg ervoor dat alle output aan onze schrijfstijl voldoet.”
Dan kan de Ticket-beheerder agent die Schrijfstijl-Skill inladen wanneer nodig. Dat is niet dubbel werk, dat is praktisch. De Agent delegeert een onderdeel van zijn taak naar gespecialiseerde instructies.
Dit illustreert eigenlijk een belangrijke nuance: Skills zijn voor “volg de regels” - je wilt consistency en standaarden. Agents zijn voor “maak het beter” - je wilt dat iemand nadenkt, itereert, verbetert. De Ticket-beheerder hoeft niet na te denken over schrijfstijl (daar zijn regels voor), maar wel over wat de beste aanpak is om tickets op te lossen.
Ik dacht eerst, Claude Code is een assistent die me helpt. Ik zit aan het stuur en Claude voert uit.
Maar met agents gebeurt er iets anders. Je gaat delegeren. Je zet specialisten in. Je hebt minder controle per moment, maar je hebt meer output totaal. Omdat agents parallel kunnen werken. Omdat ze zelfstandig kunnen itereren. Omdat ze context ruimte hebben om écht diep te gaan.
Skills passen in het “Claude helpt me” model. Je bent stuurman. Claude is copiloot.
Agents passen in het “ik delegeer werk” model. Je bent projectleider. Claude je team.
En gaandeweg ontdekte ik nog iets: je kunt deze twee ook combineren in je workflow. Je zet Agents in voor de exploratie en verbetering. Laat ze het werk beter maken, dieper graven. En als je tevreden bent met het resultaat, vertaal je die kennis naar Skills. Die worden dan de regels en standaarden die je altijd wilt toepassen. Agents voor de vraag “hoe maken we dit beter?”, Skills voor de regel “dit doen we altijd zo”.
Ik ga mijn ISO-test Skill omzetten naar een Agent. Niet omdat het technisch beter is, maar omdat ik wil dat die zelfstandig code doorloopt, fouten markeert, voorstellen test en rapporteert. Ik wil delegeren. Ik wil dat die specialist eigenaarschap neemt.
Dus: heb je werk dat complex is? Dat iteratie nodig heeft? Dat je parallel wilt doen? Maak een Agent.
Heb je werk dat consistent moet en deel van je standaardproces? Maak een Skill.
De keuze bepaalt eigenlijk hoe je Claude Code gaat ervaren. Of je Claude als assistent voelt, of als team.
2025-12-18 18:25:55
Ik weet niet hoe het met jullie zit, maar we worden overstelpt met de Wrapped tours deze dagen. Het begon natuurlijk bij Spotify maar inmiddels hebben LinkedIn, Apple, Reddit, Discord en anderen ook deze eindejaars-truc gevonden voor een glimlach over de hoeveelheid data die ze verzamelen… Ik kreeg net de Raycast Wrapped. Hoevaak open ik deze applicatie-snelstarter, welke apps open ik er mee, welke scripts en op welk moment van de dag. Schijnbaar is deze Hotkey Hero op maandag om 8:00 het meest actief… Wat ze zelf er over zeggen: Disclaimer: Most of the data displayed is stored locally, and Raycast does not have access to it. If you moved between machines during the year, some of the data might have been lost.
2025-12-13 18:23:43
Deze week heeft Jurjen de Vries mij bijgepraat over het Nostr protocol. Nostr staat voor Notes and Other Stuff Transmitted by Relays.
Waar zal ik eens beginnen… Zie dit als een train of thought om mijn eigen eerste gedachten te delen met jullie. Ik weet nog lang niet alles over deze relatief nieuwe ontwikkeling, maar het is enorm boeiend wat het mogelijk kan maken.
Ten tijde van Mastodon was ik al onder de indruk van de technische mogelijkheden van de decentrale servers en het protocol Activitypub. Er is niet één bedrijf dat Mastodon beheert of centraal aanstuurt. Dat voelt al een stuk vrijer dan alles bij Meta, X of Google op servers zetten. Met alle mogelijke gevolgen van dien (algoritmische fuiken, dataverlies, polarisatie, censuur).
Nostr gaat nog een stap verder. Nostr is de naam van het protocol dat het mogelijk maakt om allerlei soorten berichten te delen met een netwerk, maar er is niet één netwerk dat al jouw berichten in beheer heeft. Voor veel mensen is een hobbel bij Mastodon de serverkeuze. In tegenstelling tot X, Instagram etc kies je hier een server die bij je past om een account aan te maken. Dat zorgde al voor stress bij mensen. Want kies je wel de juiste server? Ik zit op indieweb.social, omdat ik dat gedachtengoed ondersteun. Maar er zijn servers die stoppen. Dan is de kans dat je je berichten en je profiel kwijt bent. Je moet je Mastodon account veranderen omdat je naar een andere server moet verhuizen.
Bij Nostr werkt dat niet zo. Daar heb je één profiel waarmee je op allerlei diensten kunt aanmelden om verschillende activiteiten te doen. Zo kan ik met mijn profiel op een klassieke tijdlijn berichten sturen en antwoorden op anderen. Met hetzelfde profiel kan ik bij een hele andere dienst bookmarks bijhouden. Ik hoef geen account aan te maken, ik log in met mijn profiel. Weer een ander biedt een boekentracker aan, om a la Goodreads bij te houden wat je leest. Kan ik met hetzelfde profiel doen. Er zijn videostreaming sites, projectmanagement diensten, games, muziek, er worden allerlei nieuwe services ontwikkeld als alternatief voor centrale server-based apps.
Het bijzondere is, al die diensten die ik hier noem, staan los van elkaar. Het zijn bestaande diensten, gemaakt door verschillende partijen. Maar ze bieden het allemaal aan over hetzelfde protocol.
Het enige dat jij hebt is een unieke sleutelcombinatie. Een privé sleutel die je bewaart alsof het je huissleutel is én je pincode. En een publieke sleutel die je kunt delen met de wereld. Je hebt dus geen email adres nodig om je te verifieren. Of een telefoonnummer, gezichtsherkenning of een kopie van je paspoort. De sleutelcombinatie zorgt dat de services weten dat jij bent wie je zegt dat je bent. Die sleutelcombinatie is wel weer te koppelen aan een leesbare accountnaam. Zo kun je hier mijn account zien. Maar er is niet één plek waar je dit kunt zien. Als je hier naar mijn profiel gaat en op het QR icoon klikt (links naast de follow-knop) dan zie je er onder een public key. Die kun je bij allerlei nostr-diensten invoeren om te zien wat ik doe.
Er is nog veel meer over te vinden en te ontdekken. Een paar sites die ik nog verder wil uitpluizen zijn
Ik ben weer op ontdekkingstocht. Mooi!
2025-12-07 21:36:23
Twee leuke toevoegingen die voor mij het werk in Claude Code net iets prettiger maken…
Je kunt in je ~/.claude/settings.json de waarde “companyAnnouncements” maken. Hier kun je zelf opstartteksten maken. Vooral leuk voor jezelf als je Claude Code opstart, verder heeft het weinig waarde, tenzij Claude Code binnen een afdeling centraal wordt geadministreerd.
Daarnaast heb ik een statusline aan mijn Claude Code toegevoegd. Hiermee zie ik in één oogopslag in welke directoy ik werk, welke git-branche eventueel actief is, met welk LLM model je werkt en hoe het met de kosten zit. Met name dat laatste was vandaag wel handig. Ik bleek alweer door mijn tegoeden te zijn dus heb nu écht even pauze van het scherm!
