By putting a "works in any browser" badge on your site, you legally consent to receive bug reports from me when I use your site in the SerenityOS Browser, NetSurf, LiteHTML, Servo, dilloNG, and w3m.
Many open standards can support profile hydration:
Ariadne: map an email identifier to supported verified accounts.
The IndieWeb: map a webpage with h-card to any account, with less-robust reciprocal-link verification.
WebFinger: map an email-like identifier (an acct: URI) to a list of links.
vCard: upload a vCard containing profile information, possibly with âshare contactâ.
I think h-card-based hydration is the best place to start. We can later add support for more options:
Keyoxide profiles already contain h-card microformats, so we get that for free.h-card microformats can have u-key properties, potentially triggering an Ariadne-based verification of accounts enumerated by the h-card.h-card can map to vCard4
Depending on how keyoxide-web issue 141 goes, WebFinger could also indirectly give Keyoxide support.
A rough timeline of QUIC support in OpenSSL-like libraries:
BoringSSL implements QUIC.Quiche, a QUIC library, requires BoringSSL. Nginx can be patched to use Quiche for HTTP/3.Nginxâs experimental QUIC branch (nginx-quic) is released. It requires BoringSSL.Some organizations (mostly Akamai) fork OpenSSL to implement the BoringSSL QUIC API, calling their fork QuicTLS. They plan to upstream changes.nginx-quic supports building with QuicTLS too.OpenSSL decides against the BoringSSL API and declines QuicTLS patches, preferring to write their own incompatible implementation.LibreSSL implements the BoringSSL QUIC API.nginx-quic can link against LibreSSL as well as BoringSSL and QuicTLS; they all use similar APIs.
(I believe wolfSSL is mostly compatible with the BoringSSL QUIC API, but I might be wrong.)
Developers will have a harder time supporting multiple TLS implementations, hurting the viability of e.g. LibreSSL-based distributions.
A rough timeline of QUIC support in OpenSSL-like libraries:
BoringSSL implements QUIC.Quiche, a QUIC library, requires BoringSSL. Nginx can be patched to use Quiche for HTTP/3.Nginxâs experimental QUIC branch (nginx-quic) is released. It requires BoringSSL.Some organizations (mostly Akamai) fork OpenSSL to implement the BoringSSL QUIC API, calling their fork QuicTLS. They plan to upstream changes.nginx-quic supports building with QuicTLS too.
UX tip: Matrix and XMPP clients donât need lock indicators for large-enough E2EE rooms. Youâll know the room has encryption enabled because someone will say theyâre getting decryption or key-fetching errors.
Bank: âWe will share this personal informationâ Me: âplease donâtâ
Bank: âCall this number to opt outâ Me: âokay coolâ
Bank: âYour call will be recorded and we will generate a voice print from your voice so we can uniquely identify your speechâ Me: âwhat the fuckâ
For personal reasons, I am stepping away from or reducing my involvement in some communities to better focus on other things. You will likely hear from me less.
My site will probably update less frequently too. Some timed posts may fire, but I wonât be actively writing much. I most likely wonât POSSE those timed posts.
Iâll probably be back eventually, but not for a while.
Most of these are pages that blur the line between âdocumentâ and âappâ, containing many interactive controls. Being concerned about them is valid; however, I think the concern is misplaced at this stage.
For an independent engine, Iâm more interested in simple âweb documentsâ. Those need to work well before tackling âWeb 2.0â territory. Specifically: articles progressively enhanced with images, stylesheets, and maybe a script or two. Understanding how well Web 2.0 sites render isnât really useful to me without first understanding how well documents render.
When testing my site, my main pain points are: a lack of support for <details>, misplaced <figcaption> elements, my SVG profile photo not rendering (it renders when I open it in a new tab), and occasional overlapping text. The only non-mainstream independent engine I know of that supports <details> is Servo.
Most of these are pages that blur the line between âdocumentâ and âappâ, containing many interactive controls. Being concerned about them is valid; however, I think the concern is misplaced at this stage.
For an independent engine, Iâm more interested in simple âweb documentsâ. Those need to work well before tackling âWeb 2.0â territory. Specifically: articles progressively enhanced with images, stylesheets, and maybe a script...
The core elements of a people-focused (as opposed to a community-focused) social network are subscribing to people for content and interacting with their content. Atom (and RSS) feeds already provide âsubscriptionâ functionality; what if we went further?
Atom feeds can serve as the foundation for distributed social media. The OStatus protocol suite describes how Salmon, ActivityStreams, and threading extensions can turn an Atom feed into a âsocial media feedâ that people can interact with. Throw in WebSub for real-time push-based updates. This OStatus + WebSub system was the precursor to the current ActivityPub-based Fediverse.
The IndieWeb has similar concepts. The IndieWeb community uses microformats for metadata, including the h-feed feed format. It also uses Webmentions for interaction between sites.
The best part of this approach is the simplicity. Besides a Webmention receiver and a WebSub hub, all you need is a static server to deliver markup files. A separate program on your machine (i.e. not necessarily your server) can ping your WebSub hub and send Webmentions; I happen to like the command-line program Pushl. Once all the pieces come together, you start to wonder why we let social media companies flourish instead of lowering the barrier to join something like the IndieWeb. This is what the Web is made for.
The core elements of a people-focused (as opposed to a community-focused) social network are subscribing to people for content and interacting with their content. Atom (and RSS) feeds already provide âsubscriptionâ functionality; what if we went further?
Atom feeds can serve as the foundation for distributed social media. The OStatus protocol suite describes how Salmon, ActivityStreams, and threading extensions can turn an Atom feed into a âsocial media feedâ that people can interact with. Throw in
What if Firefox and Chromium placed a year-long moratorium on all new browser features unrelated to security, accessibility, and internationalization? Effort not spent on those initiatives could be re-directed towards bugfixes.
Defining the word âmajorâ might be hard but I think itâs an interesting idea.
Iâm not too worried about including Safari since it could spend those months catching up.
What if Firefox and Chromium placed a year-long moratorium on all new browser features unrelated to security, accessibility, and internationalization? Effort not spent on those initiatives could be re-directed towards bugfixes.
Defining the word âmajorâ might be hard but I think itâs an interesting idea.
Some of my coworkers subscribe to my site's feeds using Microsoft Outlook. Outlook doesn't support XHTML feed contents, but it does support escaped HTML feed contents. My Atom feeds use XHTML but my RSS feeds use HTML, so I re-introduced RSS discovery for them.
Also, Outlook renders feed contents using the same HTML renderer it uses for emails. That HTML renderer is the Microsoft Word HTML renderer. Word's HTML renderer is based on Internet Explorer's MSHTML (Trident).
So IE was sunset on consumer editions of Windows two days ago, but I guess it lives on like this. I updated my my thoughts on IE's not-quite-demise to reflect that: https://seirdy.one/notes/2022/06/15/internet-explorer-is-almost-gone/
Some of my coworkers subscribe to my site's feeds using Microsoft Outlook. Outlook doesn't support XHTML feed contents, but it does support escaped HTML feed contents. My Atom feeds use XHTML but my RSS feeds use HTML, so I re-introduced RSS discovery for them.
Dilloâs domain name has expired, making it impossible to fetch its Mercurial repository from its canonical location. Fortunately, Mercurial is a distributed version control system, and I had a copy. I pushed my copy to hg.sr.ht; you can see it there.
âsystemd has the right goals but also has poor architecture: i like operating it but i donât like its underlying designâ is so much harder to digest than âsystemd goodâ or âsystemd badâ
âsandboxing is good when done in a way that gives users the ability to control how their programs run, and doesnât have to make your computer locked down like iOSâ is harder to digest than âsandboxing goodâ or âsandboxing badâ.
âverified boot that lets users control the signing key allows users to verify that the boot sequence is what they want it to be, ensuring that their FDE isnât compromised; however, most existing implementations give vendors control that should belong to usersâ is harder to digest than âverified boot goodâ or âverified boot == DRMâ.
itâs hard not to sound like a corporate shill, which is the opposite of what Iâm trying to be whenever I start talking about security. Fossbros have given the entire FLOSS community these warped preconceived notions on what sandboxing, verified boot, and even Systemd are and arenât.
it sucks to have nuanced views on the internet
âsystemd has the right goals but also has poor architecture: i like operating it but i donât like its underlying designâ is so much harder to digest than âsystemd goodâ or âsystemd badâ
âsandboxing is good when done in a way that gives users the ability to control how their programs run, and doesnât have to make your computer locked down like iOSâ is harder to digest than âsandboxing goodâ or âsandboxing badâ.
devs of bloated software should have to make a pilgrimage to bangladesh and inhale the fumes of the e-waste burn pits to understand the carbon footprint of their bloaty software causing people to buy new computers.
Lots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites, and some have been going so far as to ask FLOSS maintainers to patch their software to make this the default.
If you read the actual proposals and W3C specs, youâll find a different story.
Everybody: please calm down, take a deep breath, and read before you make such prescriptive advice.
FLoC is terrible, but telling everyone to add a magic âopt-out headerâ in every situation conveys a misunderstanding of everything you need to know about the opt-in/out process.
Lots of people have been spreading the often-unnecessary advice to add a Permissions-Policy response header to their sites, and some have been going so far as to ask FLOSS maintainers to patch their software to make this the default.
Gregory's Server
@Seirdy they shall test it in the original WorldWideWeb browser.