Our new friend, the data url

Background

In this post Skyjake, the author of Lagrange described some ideas for the usage of the data url scheme. This has caused some controversy (and more) among geminauts. I believe he has rather eloquently stated his position and I won't repeat it. My position, in short, is one of agreement with Skyjake. I see the data url as being extraordinarily useful so long as it is not abused. Of course, potential does exist for abuse, and this should be worked out among the community. I would personally like to see this addressed in the gemini spec along with a maximum length for url's, and I think that would be enough to prevent any serious abuse.

Lagrange will not be the only client supporting data url's

That's right. Eva now supports loading data from a data url in the form of images and text/plain or text/gemini. Clicking on a data url will not, howeever, display the content inline, as Lagrange does, but instead replaces the current page with whatever that content might be. I considered a couple of different ways to handle this, including displaying the contents in a new tab or just saving the data to disk and opening with an external program. In the end, I plan to eventually have the "Open link in new tab" context menu working, which will allow the former, and I have plans to include a cache in GemView, which would save page source and allow downloading the content (along with significantly speading up traversing back and forward through the history). Those features are of course not yet implemented, but considering the pace of the project so far I hope that nobody doubts they will be delivered.

This was not really all that difficult to implement, and along the way some of the needed support for a few other features made it's way onto both GemView and Eva. For starters, GemView now has functions to display plain text and to render a PixBuf. I'll be adding support for rendering an image from a Vec[u8] block of data soon, which opens up loading images from a gemini url, but much of that code is now already present.

Some other potential uses for the data url

In addition to what Skyjake described, I can see a couple of other cool things that this would enable. Now, Gemini space is full of technical people, and a lot of gemlogs are written by people who code. You can display preformatted text using gemtext markup, but sometimes you might just want to display a snippet and then link to the complete code. Think of the data url as an attachment, just like we have attachments in email. You could easily paste in a small code snippet and then attach the full source file using a data url.

How about attaching a vcard instead of linking to all of your various contact info? Such an attachment could be downloaded and imported directly into an address book.

Give a "sensitive content" warning rather than displaying that content inline.

Really, the limits to what can be done here are only what you can imagine, and fit into a certain amount of space.

Thoughts on preventing abuse

Really, the only real thing I see needing done would be to put a max size on the data url. I may even implement this in GemView before any community concensus emerges.

There are a few other considerations I suppose. It might be a good idea to limit the types of files that could be shared in Gemini via the data url. Right now Eva only cares about text and image attachments, and I think that's a good start. But I wouldn't want someone to implement a scripting language where a data url could be used to deliver active content, for instance. Gemini must remain the quiet refuge from the web that it is today. We don't need animations and interactive applications. It's a place to go and share ideas primarily through the written word, not an entertainment portal.