How does the Blockstack local daemon know how to render a given name?

[shea256]

Question:

How does the Blockstack local daemon know how to render a given name? Should it render it as a profile or as a site?

Options

• Option 1: Hardcode certain TLDs to have certain behaviors
• Option 2: Reserve a special subdomain for rendering profiles (like me.ryan.id)
• Option 3: Use HTML files for everything and include a special element in the HTML that indicates that the page should be rendered differently

[shea256]

Tagging @larrysalibra on this as he requested we move the conversation here.

[shea256]

@csuwildcat said:

Personally, I think of the visual rendering of an entity type as a UA-elective display (wherein UA = the browser or app doing the render). Much like Chrome, Firefox, and Edge have chrome pages that are basically templates for rendering data in a way to present it to the user - think Settings, chrome:flags, etc. - this could be your UA choosing a template for Person entities, another for IoT devices, and another for Events. (btw, browser chrome = the brower’s privledged chrome UI and pages, not Chrome the browser - that name was fun for vendors to disambiguate)

This would mean that you look at an entity type and render a page template that is specific for the type. You may only have 5-6 specialized, common templates, and one general fallback that all other less common types fall to.

Make sense?

@shea256 said:

@daniel B Yes I believe that falls in line with Option 3 above and is basically what I was thinking there. The HTML file would have no styling (or could have default styling that the browser can choose to ignore). The important part of the file would be a script tag with JSON data inside of it. Then the browser can choose to parse this and build a new HTML by combining it’s template and the JSON data.

Next question: Where would entity templates be stored? In the short term, they’d need to ship with the Blockstack app so that existing browsers will have support for this rendering process.

@csuwildcat said:

“They’d need to ship with the Blockstack app so that existing browsers will have support for this rendering process.” - In the world, the Blockstack identity manager app is a User Agent, and wouldn’t need to support this for other browsers. Another browser (UA) would have their own templates and process of display.

[csuwildcat]

Why is the daemon rendering anything? That's like saying "How should an HTTP server in Node render content it receives". Rendering should be left up to the User Agent, which in this case would be the User Management App, a browser, or a native client app.

[shea256]

@csuwildcat Good point. I'll respond to this in a bit.

[csuwildcat]

Few additional points to consider:

I would avoid all the Options 1-3 above. Make the profile object the entity expresses itself as be the control plane for how to render it, and let each receiving app/UA choose how that is done. This is the most generative and least rigid option, which allows for ecosystem flexibility.

Here's what I would imagine the flow looking like:

1. Daemon fetches data from local Hub or remote
2. Daemon passes data received to the app/UA that requested it
3. Receiving app/UA renders the data in the way it chooses.

A good example of this is a browser's view for directories. Each browser chooses a different template for displaying files and folders of an exposed directory structure it receives, the browser is not passed a rendered HTML page from lower in the stack.

[larrysalibra]

Tagging @larrysalibra on this as he requested we move the conversation here.
I suggested we move to the forum. Are we gonna walk the decentralized walk or what? ;-)

@csuwildcat wrote

Here's what I would imagine the flow looking like:

1. Daemon fetches data from local Hub or remote
2. Daemon passes data received to the app/UA that requested it
3. Receiving app/UA renders the data in the way it choose

That ideally is how I would imagine it as well.

The challenge is that since we don't control browsers, that would mean someone entering ryan.id in their browser would get a bunch of profile JSON.

One option would to use the http Accept header to negotiate content format.

curl --header "Accept: application/json" -I https://ryan.id would return the profile (or other data).

curl --header "Accept: text/html" -I https://ryan.id would return the profile with whatever template.

Existing web browsers request html by default. If and when they decided to support rendering Blockstack IDs, they could change the request headers to get the JSON version and use their own templates.

Option 1: Hardcode certain TLDs to have certain behaviors

I lean towards option one. Take Blockstack ID as an example. Experience with OpenID showed that people have trouble thinking about a domain name or a URL as their personal identity. I'd go so far as to say that the for identity at least, the fact that Blockstack IDs end in .id should be hidden from the end user when possible as an implementation detail.

[shea256]

I'm against hardcoding behavior according to TLDs, but in our discussion @jcnelson had a great idea.

We can put a TXT record in the zone file that indicates how domain should be resolved and how data should be passed off to the user agent.

The TXT record can have instructions that indicate something along these lines: "this subdomain points to a JSON file - proxy a request to it, grab the JSON, fold into an HTML template, process the template into HTML, then pass the HTML to the user agent".

Only the Blockstack app will know how to interpret these at first, but Blockstack names (like .id) can only be resolved with the Blockstack app anyway. In order for future user agents to delegate to these names, they'll need to talk to a Blockstack server.

I believe @larrysalibra and @muneeb-ali really liked this idea as well.