I Added Scripting To Gemini

I wrote a gemlog about it. It doesn't break the spec and works in all clients.

Gemini Scripting Revisited

In a nutshell, it's a service that interprets gemini pages with embedded JavaScript. There are a couple example programs at the link including a simple game. Because scripts have the ability to request data from the user, it's much more useful than first thought.

๐ŸฆŽ bluesman

Jul 09 ยท 3 months ago ยท ๐Ÿ‘ jsreed5, LucasMW, clseibold, Breebee

21 Comments โ†“

๐Ÿš€ LucasMW ยท Jul 09 at 13:52:

Interesting. My understanding is that, from the perspective of the user, your capsule is a gemini "client" which runs JS.

(despite it actually being run on the server)

I mean, could be useful for something. But raises a lot of questions about security and privacy.

๐ŸฆŽ bluesman [OP] ยท Jul 09 at 14:19:

@LucasMW I know it could be useful if someone has the chops. What concerns do you have about security and privacy?

๐Ÿš€ LucasMW ยท Jul 09 at 14:48:

@bluesman For what I understand, in this system's design, every js execution runs at your server.

Therefore, this server has access to the pages visited and every parameter ever passed to these scripts.

It is very easy to see how this could be a perfect setup for data collection.

๐Ÿš€ LucasMW ยท Jul 09 at 14:51:

There are other things too: imagine that some party has this server which runs every script and collects all the data.

Someone can do a malicious exploit that manages hack the server in such a way to extract and leak all the data.

Or even, hack the server silently and install their own data collection code

๐Ÿš€ clseibold ยท Jul 09 at 16:36:

It's fine if it's sandboxed properly, but sandboxing can sometimes be tricky.

๐Ÿš€ jsreed5 ยท Jul 09 at 18:14:

The idea is interesting: essentially a CGI that executes code given to it by the user rather than running pre-built code. How do you manage security and resource consumption server-side? I'd imagine this would be difficult to scale.

๐ŸฆŽ bluesman [OP] ยท Jul 09 at 18:17:

@LucasMW If a script doesn't require user input then it's no less secure than say, Fumble Around. I love that site, BTW. If the script does ask for input, it's no less secure than any other capsule that asks for input. I wouldn't write a tax preparation app with it but moves in a game (or anything else I've ever seen on Gemini) wouldn't be worth collecting even if I were nefarious. Sure, my server could get hacked like any other server. Someone could grep the logs and find out how many times it took some IP address to guess a random number.

My advice is don't type anything you don't want known into any status 10 dialog (or titan edit box, etc). It doesn't matter if it's my site or yours.

๐ŸฆŽ bluesman [OP] ยท Jul 09 at 18:33:

@clseibold, Sandboxing is tricky. Luckily, I'm using GraalJS which comes with different security profiles. The one I'm using disallows Java access, file I/O and networking (among other things).

If there's a bug in Oracle's software, my vert.x process doesn't run as root so the worst they could do is delete the contents of my server folder. That would be a bug worth reporting!

๐ŸฆŽ bluesman [OP] ยท Jul 09 at 18:44:

@jsreed5 In addition to sandboxing, GraalJS gives me control over heap memory, cpu time, max statements, max stack frames, max threads and max AST depth (among other things).

If you try running:

while(true){
    print("Hello world");
}

Execution will be stopped with an error message. I imagine this scales pretty well. My server has 1 gb of memory and 2 cores and I've been pleasently surprised. I do have an update to make script interpretation happen on a worker thread instead of the event-loop but so far, so good.

๐Ÿš€ LucasMW ยท Jul 09 at 20:31:

@bluesman I know. I am not accusing you of anything. Just thinking what would be like if like every gemini capsule had JS scripting running into a single server. In truth, that server would be able to see everything.

๐ŸฆŽ bluesman [OP] ยท Jul 09 at 21:29:

@LucasMW I only log requests so I don't see the pages or code running through the script engine but I get what you're saying.

Honestly, I don't expect too many people to use it so the honor of "seeing everything" will still belong to the search engines. I think it's an interesting experiment and I'm going to keep it running as long as it doesn't crash my server. I might create more advanced js programs to explore the limits. I thought about porting my Zoe game but no one plays the CGI version anyway (I'm beginning to sense a pattern).

๐Ÿš€ clarahd ยท Jul 10 at 11:21:

Gemini's biggest asset, like the Atom Man , is being small.

If the Atom Man goes on a sumo wrestler regime, the benefit (added strength) detracts from his primary asset (being small).

Gemini REMOVED features to the point it is accessible without:








It is therefore easy to re-add features where so much has been taken away.

But is the benefit worth the cost?

In your example, I think the cost is acceptable for a feature used on your own sites.

But if it is used more widely, it becomes a defacto added spec, and the spec adds bloat, e.g.browsers that process the script locally for better performance, browsers that extend the spec, etc.

So a cool feature? Yes.

But not as a gemini extension, defacto or otherwise, unless a case can be made for the benefit vs cost.

I would like such a javascript server that converts the javascript of the already bloated web to gemini though, as a stopgap, but does not affect the gemini spec.

๐Ÿš€ clseibold ยท Jul 10 at 12:42:

@clarahd This is just server side scripting, so there is no cost for clients. I don't see clients implementing this as there's not even a defined DOM or APIs for manipulating the page, so it's not very useful in general on the client. That any it only further increases development time for clients.

The analogy doesn't make much sense to me: it's almost saying everything has to fit in one box, and people can't be multidimensional or have multiple skillsets. I find that to be a dull and very inaccurate way to view humans in general, personally.

AntMan does in fact have multiple skillsets outside of being small. He's a combatant, stealthy, proficient in technology, can communicate with insects, has leadership qualities, and is a strategic thinker. None of these detract from his skill in being small, they only add to it.

๐ŸฆŽ bluesman [OP] ยท Jul 10 at 12:50:

@clarahd Nothing about it violates the spec so there's no way for it to become "defacto added spec". It's a service - like Fumble Around or NewsWaffle. It places zero burden on Gemini users or authors of Gemini clients.

It's basically CGI for people without access to CGI.

๐Ÿš€ jsreed5 ยท Jul 10 at 13:15:

Do you plan to release the source code for Scriptonite? It could be very useful as a self-contained, Gemini-oriented CGI framework.

I imagine a scenario where Scriptonite is the only executable file inside a capsule's 'cgi-bin' directory, so all maintenance, development and security can be focused there. It has a configuration file with a whitelist/blacklist for which URLs can be loaded. A capsule operator can then restrict the service only to URLs on his own capsule, or he could act as a public Scriptonite host for others.

This could work especially well if Scriptonite had an option to print everything on the Gemtext page as-is that isn't inside a code block. Capsuleers could write all the static content of a page in Gemtext directly, while Scriptonite is only used to execute the dynamic parts. That would greatly simplify writing CGI scripts for Gemini.

๐Ÿš€ clseibold ยท Jul 10 at 15:25:

@bluesman @clarahd That and, imo, nobody should place the burden of ruining the Gemini ecosystem, or violating the spec, on someone who decided to make a server-side scripting engine, when the burden should be placed on those who use the idea as inspiration to create client-side scripting.

Like, if someone is inspired by bluesman's idea and ends up implementing JS in a Gemini client, it's their decision, not bluesman's.

@bluesman Your idea is very similar to what is essentially PHP, just with JS, although I find two main differences: using it as a service, which is pretty interesting and novel, and the thing I find way more interesting, which is how you've implemented input (basically like forms) with URL parameters.

While I appreciate the scripting stuff for server-side scripting, the way you've implemented input is vastly more interesting for me, both in how it uses URL parameters, and in designing a better API in CGI scripts and servers for more easily creating forms in Gemini.

The idea that you can just specify parameters that you want, and the server will automatically check if the parameter was specified, and if it wasn't, will automatically prompt for the input, is really cool and makes server-side development so much easier!

It has inspired ideas for my own Gemini golang server API.

My only concern is what the response/reaction will be to a more widespread use of URL parameters, since they are kinda bypassing query strings as another way to specify multiple inputs.

Although, the spec never handled URL parameters, so if Solderpunk never intended their usage, then he should have handled their use in the spec ealier, especially since the idea of using URL parameters has been pointed out several times by various people.

๐ŸฆŽ bluesman [OP] ยท Jul 10 at 16:13:

@jsreed5 Last thing first. Scriptonite already outputs everything on the page that isn't in a "code block". It does resolve relative links however so it's not a carbon copy.

Right now, Scriptonite is not CGI. It's coded in Java directly in the "GeminiVerticle" of my vert.x server. I do want to release the Gem.X server code but it needs a lot of cleanup. That said, I think Scriptonite could be CGI (and I wish I had thought about that when I started).

I'm pretty sure it could even be a compiled Graal native-image. I did something very similar at my old job a few years back. At some point (because it sounds like a challenge), I'll probably try to get Scriptonite working as a standalone CGI program.

Also, I like the idea of a whitelist/blacklist. Very interesting.

๐ŸฆŽ bluesman [OP] ยท Jul 10 at 16:49:

@clseibold I'm glad you were inspired. That's saying something!

The one thing missing from the url parameter scheme is the inability to set the type 10 prompt text (instead of using generic verbiage with the variable name). My solution is to add the url encoded prompt to the variable name.

firstName:Enter%20your%20first%20name;lastName:Enter%20your%20last%20name

Once the vars are populated by the user, a redirect cleans it up for copy/paste/bookmarks, etc.

firstName=Joe;lastName=Smith

I'm also planning to pass in a boolean that the js code can use to check if there's a client certificate. The js code can then make a cert request if it's false. When there is a cert, a Java method to save a String or Map (probably length constrained) will be made available. There will be another method/function to load previously saved data for that client cert. This could be used for saving state without having to worry about packing it all into a url variable.

๐Ÿš€ clarahd ยท Jul 11 at 11:20:

@bluesman it doesn't "violate the spec" because it uses preformatted text. Then it is fair if I also want style guides and table processing? Adhoc with no cost benefit analysis? Unilaterally by whoever?

๐Ÿš€ clarahd ยท Jul 11 at 11:23:

@clseibold I might have botched that analogy. I meant if the Atom could no longer squeeze through microscopic openings in the wall due to his new Sumo bod, he might want to rethink that cost benefit tradeoff.

๐ŸฆŽ bluesman [OP] ยท Jul 11 at 13:39:

@clarahd It wouldn't violate the spec if I used instead of preformatted text. The pages fed into Scriptonite are basically templates that can also be viewed by any Gemini client. Preformatted text makes sense because that's how we view code in Gemini anyway.

I'm not sure about your analogy but if you want table formatting you could probably emulate what Gemipedia does in Scriptonite (or CGI if you have server access). That might be a cool library.

Source