JSContact; RFC 9562: Revenge Of The UUID; Everything Is AIwful

A couple RFCs (I really tried to make them not dry sections), paired with a new, occasional section on the terrible impacts of AI, await intrepid readers today.

(I’m still working on the de-Perplexified TL;DR section, but shld have that ironed out by Wednesday).

JSContact

Before we discuss the section topic, we have to wax poetic about vCards.

The creation of vCard, a cyber-incarnation of the traditional business card, is a tale of the ages (not really, but I have to make this interesting somehow). Forged from the collaborative efforts of the Versit Consortium — which counted orgs like Apple, AT&T, IBM, and Siemens as part of its globalist cabal — vCard was initially crafted in 1990 as a means to standardize the way contact information was exchanged across the burgeoning digital landscape.

This initiative was a response to the growing need for a uniform format that could help fend off assaults from proprietary formats from wanna be cyber dictators. The vCard, with its .vcf (Virtual Contact File) extension, became a versatile and widely accepted standard, encapsulating contact details in a format that could be attached to emails, embedded in web pages, or exchanged through various digital mediums.

The vCard format continued to evolved and was eventually handed over to the Internet Mail Consortium (spooky name tbh), and later to CalConnect. Each handover was accompanied by enhancements to meet emerging needs.

Despite its utility and the broad adoption it has enjoyed, vCard has not been without its challenges. Issues of interoperability and the limitations imposed by its structure have sparked discussions and criticisms, highlighting the difficulties of creating a truly universal standard.

JSContact (1) (2) (3) is a new JSON-based data format introduced in 2024 (nearly 35 years since vCard was born!) to represent contact information in a simpler and more consistent way compared to vCard.

It aims to be an alternative to vCard by providing:

• simplicity: JSContact uses JSON, a lightweight and widely-used data format, making it easier to work with and integrate into modern applications.
• unambiguity: The specification clearly defines the data model and semantics, reducing inconsistencies in implementation.
• extensibility: As a JSON-based format, JSContact can be easily extended with custom fields or properties as needed.
• interoperability: By defining a clear data model, JSContact improves interoperability between different systems and services that exchange contact information.

Here’s a (fake) JSContact “card” for me:

{
  "@type": "Card",
  "version": "1.0",
  "uid": "A1B2C3D4-E5F6-7890-GHIJ-KLMNOPQRSTU",
  "kind": "individual",
  "name": {
    "components": [
      {
        "kind": "given",
        "value": "Bob"
      },
      {
        "kind": "surname",
        "value": "Rudis"
      }
    ],
    "isOrdered": true
  },
  "emails": [
    {
      "type": "work",
      "value": "bob.rudis@greynoise.io"
    }
  ],
  "phones": [
    {
      "type": "mobile",
      "value": "+1234567890"
    }
  ],
  "addresses": [
    {
      "type": "home",
      "street": "123 Main St",
      "locality": "Berwick",
      "region": "Maine",
      "postalCode": "03901",
      "country": "USA"
    }
  ],
  "organization": {
    "name": "GreyNoise Intelligence",
    "title": "V.P. of Data Science, Security Research and Detection Engineering"
  }
}

It reminds me alot of JSON-LD.

vCard is dead! Long live the JSContact vCard!

RFC 9562: Revenge Of The UUID

(Doing my best to make new, but important, RFCs less boring, here…)

UUIDs, or Universally Unique Identifiers, trace their origins back to the 1980s. They gathered power, slowly, over four decades, eventually taking over the enterprise empire with their contextually (I mean, I have large scale processes that generate the same UUIDs for vastly different records due to the nature of these beasts) unique 128-bit digits.

The journey of UUIDs is a tale of evolution, adaptation, and the relentless pursuit of a universal standard for uniqueness. From their early use in Apollo computers to their insidious widespread adoption, UUIDs have been a silent witness to the exponential growth of data. They have become the invisible threads weaving through the fabric of our digital interactions, from identifying records in vast databases to ensuring (well, sort-of) the uniqueness of objects in distributed systems.

The recent publication of RFC 9562 marks a new, monumental chapter in the saga of UUIDs. This document is aa product collaborative spirit of the Internet Engineering Task Force (IETF), and encapsulates the culmination of centuries (ok, “years”) of research, debate, and refinement. Woe to thee who might assert this RFC is just a mere codified technical specification! In truth, it is a beacon guiding the future trajectory of UUIDs, ensuring their continued relevance and utility for ages to come.

To get serious, for a moment, RFC 9562 updates and obsoletes RFC 4122, incorporating advancements and lessons learned since the previous standard was established. It provides a detailed framework for the generation, interpretation, and implementation of UUIDs, ensuring they are robust enough for modern computing needs

RFC 9562 also establishes a Uniform Resource Name namespace for UUIDs, which helps in the standardized identification and handling of these identifiers across different platforms and applications.

Section 6 in the RFC has some solid “UUID Best Practices“.

Also, the team notes that 16 different implementations were analyzed for trends in total ID length, bit layout, lexical formatting and encoding, timestamp type, timestamp format, timestamp accuracy, node format and components, collision handling, and multi-timestamp tick generation sequencing:

• ULID
• LexicalUUID
• Snowflake
• Flake
• ShardingID
• KSUID
• Elasticflake
• FlakeID
• Sonyflake
• orderedUuid
• COMBGUID
• SID
• pushID
• XID
• ObjectID
• CUID

(I, for one, am glad that was them and not me.)

Everything Is AIwful

Two RFC-heavy sections in a row == must change things up a bit in section three. We cover techy-AI in an occasional dedicated ThursdAI edition, but there are AI topics that do not fit that, most of which are usually horrible. So, I’ll Drop an occasional section with those in normal Drop days so you can become as depressed as I am.

AI is going to do a number on the professional job market, especially in creative spaces. This Bloomberg article talks about how Audible has introduced AI-generated voices for narrating audiobooks, offering over 40K titles with this new feature. The synthetic voices, created using advanced text-to-speech technology, provide an alternative to human narrators and offer advantages like consistent pacing, precision in complex texts, and 24/7 availability.

Sure, concerns have been raised about the lack of emotional depth and nuance compared to human narrators, but why should Amazon’s books be any different from their present senior management and former CEO?

Long-time readers will remember I have fully ditched Audible for a couple other providers, including Libro.fm (nuke the rf_code if that skeezes you out). It’s been great knowing I support a local bookstore, and I manage to burn through the same number of credits there as I used to on Audible.

One cautionary tale. Just before making the commitment to cancel, I did a pre-order on Audible. It came in weeks after I stopped subscribing there, and the book was unplayable in the app (the app kept crashing, and still does if I try). Libation worked like a champ in helping me get the book over to Book Player, but, imagine what the average human would have to go through if they decided to do the same thing?

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️