The universal, self-publishing, loosely-coupled personal directory, Part 2

Last time, we began to look at the SMBmeta initiative proposed by PC pioneer Dan Bricklin and brought to my attention by Jamie Lewis at the Burton Group.

SMBmeta specifies an XML data file (smbmeta.xml) which would reside in the root directory of any participating domain (e.g., http://vquill.com/smbmeta.xml) describing the organization, its business and its location. It’s primarily intended as a free-to-use catalog entry for a bricks-and-mortar business. At least, that was the general idea behind it.

But the file itself isn’t of much use to the average person, so Bricklin has proposed an SMBmeta Ecosystem (https://www.trellixtech.com/smbmetaecosystem.html) as a complete package to foster the development and use of the initiative.

Initially, Bricklin thought there would be independent directory applications that used spider-like technology (i.e., they would traverse the Web looking for smbmeta.xml files) to find and compile the data. Various questions and objections led to the creation of other parts of a complete system. In addition to the data files created by the leaf-points (the enterprises creating smbmeta.xnl files) there are three other parts to Bricklin’s system: the SMBmeta Registry, the SMBmeta Proxy and the SMBmeta Affirmation Authority.

The Registry allows SMBmeta data to be stored at various (and multiple) locations around the Web so that there’s no need to spider the world every time you want to find data. Registries can be manually or automatically populated using one-off entries, subscribe-and-publish or push-pull technologies.

The Proxy allows one server and/or domain to be the authoritative source of data for multiple enterprises. Very small organizations may not have their own domains(e.g., http://www..net/~abcompany/), so there’s no way for them to create an http://www.ANC.com/smbmeta.xml file. The proxy server would contain a database/directory of SMBmeta data, which it could submit to a Registry or make available to a spider on behalf of its constituent organizations.

Bricklin sees this as a way to kickstart the initiative, along with enterprising ISPs creating SMBmeta data for their hosted entities. Organizations could continue to provide the data as long as necessary, or as long as the individual enterprises cared to have them do it.

The Affirmation Authority is an intriquing concept – it is used to gauge the validity of the data found in the smbmeta files or on the proxy servers. As the spec defines it:

“For example, the Authority could indicate that the requested domain’s business type is known to be correct (a ‘good’ list), or that the requested domain is known not to be anywhere near correct (a ‘bad’ list). A Directory or Application could check on the domain’s data through a query of the Authority, or use the optional signature to check algorithmically on the authenticity of the claim of being affirmed.”

Anyone could create an Affirmation Authority (presumably you could query other Affirmation Authorities as to its validity!) with no relationship whatsoever to the domain it is validating – an interesting concept which raised some interesting questions. See the essay “SMBmeta and Spam” at https://www.trellixtech.com/smbmetaandspam.html for a fuller discussion of the role of the Affirmation Authority.

That’s how Bricklin sees SMBmeta operating, and it’s a good vision. But limiting it to small and midsized businesses could be self-defeating. Next issue we’ll begin to explore how this concept and initiative could evolve to do even more.