Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

I saw a recent discussion at work on how to approach code style for data attributes in #HTML

Uncategorized
4 3 6

Gli ultimi otto messaggi ricevuti dalla Federazione
  • @_elena Looks like good progress! Woot!

    read more

  • Aveva aspettato molto per salutarla

    read more

  • @angel we definitely do. I'm lucky enough to be able to go and see it from time to time (even if last time has been in August). So the next time I'll watch the sea, I'll dedicate it to you. Meanwhile, I'm sending you this photo, from November 2024

    read more

  • Thank you so much, Stefano. I know you and me also share The Sea as a lover, but we are reasonable and generous lovers.
    read more

  • @angel beautiful words!

    read more

  • read more

  • I'm in love with The Sea. It's a bit strange, as I'm from Madrid; it's a dry and stubborn land as far from the sea as can be. Or, who knows, maybe that's the reason of my love, the love of the dispossesed, the love of the forsaken, the love of the abandoned; a loved one, a desired one, as far as can be. I wish I was by the shore, my sight lost in the flat horizon, my feet cold and wet, the engine of the sea drumming and roaring. I'm far away, but I'm reading Oceano mare by Alessandro Baricco and I see that we share The Sea as a lover, and reading his words (an art of words I will never be able to craft) I feel a bit better, a bit closer.

    Those of you near The Sea, you'll know that I envy you. Please, give my regards to the one I love, I will be there, who knows when.
    read more

  • @6al quanto sei ottimista che pensi che le persone normali siano empatiche e solidali, quando invece sono molte di queste "persone normali" che sostengono e votano i dittatori o i partiti nazi-fascisti e populisti. Che sono a favore dei centri di concentramento in Albania, che gioiscono per i morti nel Mediterraneo.
    O che sostengono e difendono i miliardari come Musk, Besos e il tizio di Meta.
    P.S. bello risentirti, mio splendore.
    E, con ritardo, buon Natale 🎄🎄🎄

    read more
Post suggeriti
  • 0 Votes
    1 Posts
    3 Views
    When I started building Fedify, an ActivityPub server framework, I ran into a problem that surprised me: I couldn't figure out how to add logging. Not because logging is hard—there are dozens of mature logging libraries for JavaScript. The problem was that they're primarily designed for applications, not for libraries that want to stay unobtrusive. I wrote about this a few months ago, and the response was modest—some interest, some skepticism, and quite a bit of debate about whether the post was AI-generated. I'll be honest: English isn't my first language, so I use LLMs to polish my writing. But the ideas and technical content are mine. Several readers wanted to see a real-world example rather than theory. The problem: existing loggers assume you're building an app Fedify helps developers build federated social applications using the ActivityPub protocol. If you've ever worked with federation, you know debugging can be painful. When an activity fails to deliver, you need to answer questions like: Did the HTTP request actually go out? Was the signature generated correctly? Did the remote server reject it? Why? Was there a problem parsing the response? These questions span multiple subsystems: HTTP handling, cryptographic signatures, JSON-LD processing, queue management, and more. Without good logging, debugging turns into guesswork. But here's the dilemma I faced as a library author: if I add verbose logging to help with debugging, I risk annoying users who don't want their console cluttered with Fedify's internal chatter. If I stay silent, users struggle to diagnose issues. I looked at the existing options. With winston or Pino, I would have to either: Configure a logger inside Fedify (imposing my choices on users), or Ask users to pass a logger instance to Fedify (adding boilerplate) There's also debug, which is designed for this use case. But it doesn't give you structured, level-based logs that ops teams expect—and it relies on environment variables, which some runtimes like Deno restrict by default for security reasons. None of these felt right. So I built LogTape—a logging library designed from the ground up for library authors. And Fedify became its first real user. The solution: hierarchical categories with zero default output The key insight was simple: a library should be able to log without producing any output unless the application developer explicitly enables it. Fedify uses LogTape's hierarchical category system to give users fine-grained control over what they see. Here's how the categories are organized: Category What it logs ["fedify"] Everything from the library ["fedify", "federation", "inbox"] Incoming activities ["fedify", "federation", "outbox"] Outgoing activities ["fedify", "federation", "http"] HTTP requests and responses ["fedify", "sig", "http"] HTTP Signature operations ["fedify", "sig", "ld"] Linked Data Signature operations ["fedify", "sig", "key"] Key generation and retrieval ["fedify", "runtime", "docloader"] JSON-LD document loading ["fedify", "webfinger", "lookup"] WebFinger resource lookups …and about a dozen more. Each category corresponds to a distinct subsystem. This means a user can configure logging like this: await configure({ sinks: { console: getConsoleSink() }, loggers: [ // Show errors from all of Fedify { category: "fedify", sinks: ["console"], lowestLevel: "error" }, // But show debug info for inbox processing specifically { category: ["fedify", "federation", "inbox"], sinks: ["console"], lowestLevel: "debug" }, ], }); When something goes wrong with incoming activities, they get detailed logs for that subsystem while keeping everything else quiet. No code changes required—just configuration. Request tracing with implicit contexts The hierarchical categories solved the filtering problem, but there was another challenge: correlating logs across async boundaries. In a federated system, a single user action might trigger a cascade of operations: fetch a remote actor, verify their signature, process the activity, fan out to followers, and so on. When something fails, you need to correlate all the log entries for that specific request. Fedify uses LogTape's implicit context feature to automatically tag every log entry with a requestId: await configure({ sinks: { file: getFileSink("fedify.jsonl", { formatter: jsonLinesFormatter }) }, loggers: [ { category: "fedify", sinks: ["file"], lowestLevel: "info" }, ], contextLocalStorage: new AsyncLocalStorage(), // Enables implicit contexts }); With this configuration, every log entry automatically includes a requestId property. When you need to debug a specific request, you can filter your logs: jq 'select(.properties.requestId == "abc-123")' fedify.jsonl And you'll see every log entry from that request—across all subsystems, all in order. No manual correlation needed. The requestId is derived from standard headers when available (X-Request-Id, Traceparent, etc.), so it integrates naturally with existing observability infrastructure. What users actually see So what does all this configuration actually mean for someone using Fedify? If a Fedify user doesn't configure LogTape at all, they see nothing. No warnings about missing configuration, no default output, and minimal performance overhead—the logging calls are essentially no-ops. For basic visibility, they can enable error-level logging for all of Fedify with three lines of configuration. When debugging a specific issue, they can enable debug-level logging for just the relevant subsystem. And if they're running in production with serious observability requirements, they can pipe structured JSON logs to their monitoring system with request correlation built in. The same library code supports all these scenarios—whether the user is running on Node.js, Deno, Bun, or edge functions, without extra polyfills or shims. The user decides what they need. Lessons learned Building Fedify with LogTape taught me a few things: Design your categories early. The hierarchical structure should reflect how users will actually want to filter logs. I organized Fedify's categories around subsystems that users might need to debug independently. Use structured logging. Properties like requestId, activityId, and actorId are far more useful than string interpolation when you need to analyze logs programmatically. Implicit contexts turned out to be more useful than I expected. Being able to correlate logs across async boundaries without passing context manually made debugging distributed operations much easier. When a user reports that activity delivery failed, I can give them a single jq command to extract everything relevant. Trust your users. Some library authors worry about exposing too much internal detail through logs. I've found the opposite—users appreciate being able to see what's happening when they need to. The key is making it opt-in. Try it yourself If you're building a library and struggling with the logging question—how much to log, how to give users control, how to avoid being noisy—I'd encourage you to look at how Fedify does it. The Fedify logging documentation explains everything in detail. And if you want to understand the philosophy behind LogTape's design, my earlier post covers that. LogTape isn't trying to replace winston or Pino for application developers who are happy with those tools. It fills a different gap: logging for libraries that want to stay out of the way until users need them. If that's what you're looking for, it might be a better fit than the usual app-centric loggers.
  • 0 Votes
    1 Posts
    8 Views
    do you have art? do you want to put it on a website, that *you* own, for cheap-as-free?im writing a program for that! you just drag and drop your art into a folder, and run "galleryify", and it generates html for each image, and adds everything to a thumbnail gallery. you can group with tags and style everything however you want, too.it outputs static html, so you can upload it to neocities or nekoweb or basically any free web host. the tradeoff for being cheap-as-free is that there's no server-side interactions (e.g. no comment section).i need testers! if this sounds good then please comment and let me know your level of comfort with art and with html.https://nycki93.github.io/eleventy-image-gallery/if you just wanna know "the stack", this is made with NodeJS and Eleventy. if that doesn't mean anything to you, dont worry about it.EDIT: wow, a lot of you said you'd be interested in testing! Okay, I've just put some usage instructions up on this page, please try it out and let me know how it goes!https://github.com/nycki93/eleventy-image-gallery/#website #art #code #programming #html #heycohost #eleventy
  • 0 Votes
    1 Posts
    5 Views
    Alla scoperta dell’HTTP Request Smuggling: cos’è e come difendersi📌 Link all'articolo : https://www.redhotcyber.com/post/alla-scoperta-dellhttp-request-smuggling-cose-e-come-difendersi/Immaginiamo una metropolitana notturna in cui le richieste sono vagoni che scorrono uno dopo l’altro. Il front end fa da bigliettaio e smista i vagoni, il back end è il deposito che li riceve e li lavora. Se il bigliettaio e il deposito non sono d’accordo su dove finisce un vagone e inizia quello successivo, si apre una fessura che qualcuno può sfruttare per infilare un vagone nascosto. Quel vagone nascosto è il contrabbando di richieste HTTP. A cura di Diego Bentivoglio#redhotcyber #news #frontend #backend #sisteminformatici #architetturadisistemi #metropolitana #analogiedigitali #svilupposoftware #ingegneriadellinformazione #informatica #tecnologieinformatiche #sistemidigestione #datielaborazione
  • 0 Votes
    1 Posts
    11 Views
    Optique 0.6.0: Shell completion support for type-safe CLI parsers https://lobste.rs/s/rnekre #javascript #releasehttps://hackers.pub/@hongminhee/2025/optique-060