@alcinnz@floss.social avatar



A browser developer posting mostly about how free software projects work, and occasionally about climate change.

Though I do enjoy german board games given an opponent.

Pronouns: he/him

This profile is from a federated server and may be incomplete. Browse more on the original instance.

alcinnz, to random
@alcinnz@floss.social avatar

In preparation for my next metathread in my hardware-communicator hypothetical regarding self-hosted devtools, having just finished a metathread on internet communication...

Popquiz: Which popular text-editing command would be the hardest to implement on a text-centric CPU? Like the one I described?

Open-ended question: Which devtools would you want?

alcinnz, to random
@alcinnz@floss.social avatar

"What time is it?" is a surprisingly political question for our hypothetical hardware-Internet Communicator to answer! Daylight Savings is just the tip of the iceberg! So how'd we implement it?

For starters I'd offload tracking the relevant global politics to IANA's tzdb project. tzdb primarily consists of datafiles, making it trivial to port to our novel architecture! I'd ship updates the same way as any other OS update (HTTP-cached zips).

As for reading & writing dates...


@alcinnz@floss.social avatar

Most cultures split the time up into separate components based on natural cycles to make them easier to think about. Today (believing Wikipedia) most country & internet protocols uses the "Gregorian calendar" (superseding the Roman's "Julian calendar"), though there's no need to enforce that westernism if we internally use the neutral machine-friendly UNIX Epoch.

Once we've subtracted off leap seconds (as tracked by tzdb & NTP) reading/writing Gregorian dates is similar to other numbers.


@alcinnz@floss.social avatar

To a first approximation use repeated divide-with-remainder (itself a repeated bitshift & conditional-subtract) to write dates & repeated multiply-adds to parse. With constant factors.

Except... the number of days in a month varies, so its easier to work with day-of-year & use a lookup table to convert that to/from a month & date. Adjusting February for leap years.

Talking about leap years... We can calculate the number of leap years within an interval, allowing us to refine our answer.


@alcinnz@floss.social avatar

As it refines leap years Gregorian date parsers also accounts for another time changes (including Daylight Savings) for the configured or specified timezone, possibly followed by Daylight Savings postprocessing. For writing dates this is handled during preprocessing.

GPS could be handy for (amongst other things) selecting a timezone upon initial setup.

Every second I'd update a status icon or 2 & (if present) its text to communicate the current time in your timezone.


@alcinnz@floss.social avatar

The dropdown for the time status icon can render the time in other chosen timezones, schedule timeouts to popup a notification either a time-of-day or specified number of seconds, & to render the time interval since you last pressed "start".

Neglected to say: Once a date's split up into its components, different peoples write dates differently. So reformat into the local notation, possibly adding "eras". Weekday is easy to calculate from days since 1970, knowing 1/1/1970 was a Thursday.


@alcinnz@floss.social avatar

The date status menu meanwhile would render a month's (or whatever your chosen calendar's equivalent is) worth of days, with CSS3 Grid already implementing most (not all!) of this logic. Linking to a full webpage display.

Into this I'd incorporate sorted & merged iCal (RFC5545) files, with links to forms for editing individual events. You might be emailed these, HTTP/XML-query (RFC4791 "CalDAV"), or I'd log past notifications to be displayed here.


@alcinnz@floss.social avatar

iCal is a (barely) pre-XML syntax encoding calendar events. RFC5545 includes a grammar we can incorporate into our codebase. We could offer CalDAV servers listing national public holidays, for whichever nation is relevant to you.

Both time & date status dropdowns could link to forms for configuring the time & its display. Including enabling/disabling NTP.

7/7 Fin on Communicator features!

I'm taking a break to publish this metathread & then discuss devtools to self-host this!

alcinnz, to random
@alcinnz@floss.social avatar

Don’t use the maxlength attribute to stop users from exceeding the limit - Adam Silver:

A Comparison of Automated Testing Tools for Digital Accessibility - Equal Entry:

How web bloat impacts users with slow devices - Dan Luu:

When security and accessibility clash - Nic Chan:

Designing Accessible Typefaces with Eleni Beveratou - Pimp My Type:
https://invidious.perennialte.ch/watch?v=oaj7aItkj14 (YouTube via Invidious)

alcinnz, to random
@alcinnz@floss.social avatar

Will Web Components replace React and Vue? - Go Make Things:

alcinnz, to random
@alcinnz@floss.social avatar

Building a culture of accessibility - Felicity Miners-Jones @ Tetralogical:

9 signs your frontend code has quality issues that affect your users - Angelika Tyborska:

How to think about HTML responsive images - Dan Cătălin Burzo:

Beware – automatic tools over-report accessibility issues and steal your time - Bogdan Cerovac:

alcinnz, to random
@alcinnz@floss.social avatar

I'm finishing my current metathread re my hypothetical hardware-Internet Communicator tomorrow (thought it'd be today...), so here's an open-ended question to shape the next one:

What dev tools would you ideally want to help self-hosted implement this system?

I'll try to describe my take on any ideas you suggest! Though I already have several in mind...

alcinnz, to random
@alcinnz@floss.social avatar

Something I love about exploring what it'd take to build a browser from scratch hardware on up, is merely the question: What's the simplest possible hardware & operating system? Whilst still being inclusive?

It took me about a year, but I think I've almost finished an answer...

The most banal software in our lives is the most complex! For good reason!
Yet those who don't know better are more impressed by neural networks & blockchains than text renderers.

(askew echoing of a boost)

@alcinnz@floss.social avatar

@benjohn That's the impression I get!

alcinnz, to random
@alcinnz@floss.social avatar

The challenge with syncing time between is that it takes time to do so, which we must account for! NTP addresses this issue, so how'd we implement it for our hypothetical hardware-Internet Communicator?

First off we need to find nearby NTP servers hoping to minimize the latency, which can be discovered using standard IP multicast addresses. We'd want to find several to improve our resiliency.

Then to account for network latency timestamps are taken on both the server & client.


alcinnz, (edited )
@alcinnz@floss.social avatar

The client timestamps when its about to send the request & when it receives the response, whilst the server timestamps when it received the request when it finished processing it when its just about to send the response. Adding a secret-key MD5 digest for security, with precision data.

There's no guarantee that these times are perfectly in sync, but they should be close enough we can compute the time periods between them as we update our clock to match.

But what if our sources disagree?


@alcinnz@floss.social avatar

A first passes discards the least accurate sources, once we've populated a ringbuffer enough (or rather our Output Unit would prefer a plain queue, dequeueing entries once it filled up). Next we sort by the computed delays discarding non-monotonic entries, sums each server-given dispersion divided by a corresponding power-of-2 to give an aggregated dispersion. Our Arithmetic Core can readily handle this!

Next we compute an aggregated jitter using as an "RMS average".


@alcinnz@floss.social avatar

Computing aggregated involves choosing a base jitter from which we sum the squared-differences against all the other entries. This is then square-rooted & divided by one-less than the count. In our computer architecture our rudimentary Arithmetic Core would struggle more here, but it can take shortcuts (especially assuming small differences). Our FPMA would struggle even more.

Square roots can be computed similar to division using bitshifts & conditional subtraction.

Now for outliers...


@alcinnz@floss.social avatar

To discard outliers (malicious or accidental) creates a sorted list of each source-clock's low, mid, & high points. A scan from lowest to highest & back with a couple counters selects our appropriate low & high points. If this gives us a valid range use it, otherwise increment the number of "false tickers" & try again.

Then recompute the stats for the surviving clocks to determine what to set the Arithmetic Core's privileged time registers to.

Giving us UNIX epoch time with leap seconds!


alcinnz, to random
@alcinnz@floss.social avatar

QUIC is a newer protocol which drops the separation between TCP & TLS for greater efficiency. This morning I'm studying OpenSSL's implementation, in "ssl"'s "quic" sublib.

This includes;

  • Cryptography initialization.
  • Updating some stats
  • Manage threads in which the cryptography happens
  • Linked list queue of packets to transmit, each split into multiple chunks.
  • Unsigned integer set as a linkedlist of ranges.
  • A ring buffer stores incoming data before we decrypt/decode it.


@alcinnz@floss.social avatar
  • A linked list of frames.
  • Another ringbuffer, this one for sending.
  • Managing of cryptographic keys.
  • A facade over the other components, exposing a public API.
  • Debugging utils
  • Fallback adaptor to TLS/TCP
  • Track lost packets
  • Abstraction around select syscall.
  • Encrypt packets, including some of its own XOR-based crypto.
  • Manage QUIC parameters, & flow control.
  • Track packet acknowledgements.
  • More linkedlists.
  • Manage "channels".


@alcinnz@floss.social avatar
  • Parse ("demux") multiple streams from the single input.
  • Flow control handling.
  • Central bulk of the implementation, abstracting other components to work together.
  • Decrypt & parse packets, across 2 files.
  • Encrypt, serialize, & send packets.
  • Another linkedlist queue, this one tracking a receive state.
  • Non-trivial abstraction around transmitting infrastructure, including lookuptable.
  • A separate file is primarily responsible for the serialization.

3/3 Fin today! Tomorrow: LibPoppler

alcinnz, to random
@alcinnz@floss.social avatar

Now that I've established some additional UI primitives in the process of adding messaging to our hypothetical hardware-Internet Communicator I can discuss a critical step I've glossed over: Before we can surf the web or message each other we must first have a connection to the internet!

Lets say we're using WiFi.

The process starts when we receive "beacon frames", informing us which hotspots are reachable. If disconnected it might handle this by displaying a notification or connecting.


@alcinnz@floss.social avatar

Regardless I'd update a list of available hotspots to be listed under a "Network" status icon, displaying a course measure of the received wattage(?) from the currently-configured (if any) hotspot. That would allow you to switch between hotspots!

If you lose connection you'd be notified.

To connect to an encrypted hotspot we must send an "authentication frame" on its frequencies. Establishing encryption keys based an out-of-band password, possibly using a Diffie-Hellman variant.


@alcinnz@floss.social avatar

The recent addition of Diffie-Hellman handshakes to WiFi allows non-authenticated hotspots to be encrypted.

Once the cryptography has been negotiated I'd configure the FPMA to encrypt & decrypt all frames sent via the WiFi transceiver (with its realtime processing circuits).

Regardless of encryption, we'd reconfigure which transcoder handles IP datagrams so that they get sent via the WiFi transceiver over this hotspot's shifting frequencies.


@alcinnz@floss.social avatar

Having established the WiFi connection we now need to establish the IP connection. There'd be more configuration forms (linked from the network status dropdown) to hardcode these parameters, or we may broadcast DHCP request. Or randomly select an IPv6 address, pinging it in case its already taken.

The DHCP response is parsed to set the IP parameters for this host.

Finally we open a remote webpage yielding a special status code in case the WiFi hotspot redirects us.

4/4 Fin! Tomorrow: NTP!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • Leos
  • thenastyranch
  • Backrooms
  • modclub
  • magazineikmin
  • hgfsjryuu7
  • Youngstown
  • slotface
  • Durango
  • everett
  • osvaldo12
  • mdbf
  • kavyap
  • rosin
  • JUstTest
  • DreamBathrooms
  • cisconetworking
  • anitta
  • ethstaker
  • tacticalgear
  • GTA5RPClips
  • khanakhh
  • InstantRegret
  • tester
  • provamag3
  • normalnudes
  • cubers
  • lostlight
  • All magazines