Feature Request: CGI-style interface for script pages

[acehoss]

I've been having a blast scripting pages for nomadnet. I'd love to see a few CGI-like features for scripts:

• query string
• request metadata like request id and sender address (if that's available)
• host node information like address

These things, especially query string, would allow for more interactive content.

[markqvist]

Hi @acehoss! That's awesome to hear :) I've been checking out your node, and must say it's really cool.

The plan is definitely to add ability to pass more advanced data back and forth, but I haven't yet gotten down to exactly what the best way to do this is.

A few notes:

• Source addresses simply doesn't exist in Reticulum, so you have no way of automatically getting that. But, clients can freely choose to identify themselves when connecting to a node, which can provide the same kind of functionality (in a better way, I think). In nomadnet, there's a checkbox labeled "Identify when connecting", which enables this behaviour on a per-node basis. It's currently used for the authentication feature (having a .allowed file specifying what identities are allowed to interact with a page). Currently there's no access to this within executed scripts, but there obviously should be, and I could add this easily.
• It might also be a good idea to add an accessible session variable for the Link ID, since this is ephemeral and anonymous any way. I have to think over the security and privacy implications of this, but I don't think there's anything obviously wrong here.
• Form elements are a bit more complicated. Its gonna happen in some capacity at least, but I really need to be sure we are doing that right ;)

I'd love to hear your thoughts, ideas and anything else on the above and anything else related. Would also love to hear how you'd ideally like it implemented. I think something like passing this data as environment variables would probably be the most universal way of doing it, since all scripting languages and even ELF executables have access to those.

[acehoss]

The issue of form elements definitely came to mind, and there is plenty to think through with that. But I was thinking query strings could be added before form elements or even if form elements never happen. Query strings would enable pages to create dynamic links, for example a message board linking to a message.

A first pass idea is to do the same thing as CGI--any characters after a ? in the URL are set into the QUERY_STRING environment variable for the subprocess. Any of the other available data could be set into environment variables as well.

[markqvist]

I'm working on your input fields btw ;) I'll answer the other stuff later (regarding query strings), just wanted to let you know. There might be something really basic in the next release, but don't get too hyped, it'll be pretty simple ;)

[acehoss]

Wow, working on the hard part first! 😂

[markqvist]

Ok, this is getting somewhere at least :)

Even the most minimal thinkable implementation seems to balloon almost uncontrollably though ;) Here's what I am thinking to implement for now:

• Two field types, "plain" and "masked" (for passwords and stuff like that)
• Ability to control field width
• Field colors and such can be controlled using normal micron styling.
• Fields allow multi-line editing by default. Not controllable as of now. Maybe should be? (apropos implementation inflating)
• No support currently for using enter or hotkeys to submit a form/field. It will be triggered from a "normal" link (which can be styled as whatever of course)

I'm interested to hear if you have any thoughts or comments on this approach.

[acehoss]

I totally agree on the ballooning. If I let my brain go on it for a while, I always end up with "HTML, but with ticks instead of angle brackets."

That feature list seems plenty usable. Down the road it might be nice to have a single line/multiline switch. Multiline fields maybe pop open a text input dialog. Single line inputs edit in place.

[markqvist]

I just pushed the latest on this to the repo in c134ee180a1e7c9056fc5fb809f0fa722b1ecdd3.

There's still some issues with keyboard navigation (you'll have to use the mouse to focus the fields), and probably a few other things as well, but the basics are working now:

There's nothing about it in the internal guide/documentation yet, but at least there's now a small example included in the examples folder:

#!/usr/bin/env python3
import os
env_string = ""
for e in os.environ:
  env_string += "{}={}\n".format(e, os.environ[e])

template = """>Fields and Submitting Data

Nomad Network let's you use simple input fields for submitting data to node-side applications. Submitted data, along with other session variables will be available to the node-side script / program as environment variables. This page contains a few examples.

>>Read Environment Variables

{@ENV}
>>Examples of Fields and Submissions

The following section contains a simple set of fields, and a few different links that submit the field data in different ways.

-=

An input field    : `B444`<username`Entered data>`b

An masked field   : `B444`<!|password`Value of Field>`b

An small field    : `B444`<8|small`test>`b, and some more text.

Two fields        : `B444`<8|one`One>`b `B444`<8|two`Two>`b

The data can be `!`[submitted`:/page/input_fields.mu`username|two]`!.

You can `!`[submit`:/page/input_fields.mu`one|password|small]`! other fields, or just `!`[a single one`:/page/input_fields.mu`username]`!

Or simply `!`[submit them all`:/page/input_fields.mu`*]`!.

-=
"""
print(template.replace("{@ENV}", env_string))

If you give it a try, let me know if you bump into any issues!

[acehoss]

That looks very cool. The thing I keep thinking about with this is the public message board, and I think one feature that is needed yet to make it complete is the ability to send hidden text. Then it would be possible to make links that would open up messages, or a delete link for a message.

Maybe add an = to the field name in the submit link?

`[submit`:/page/delete_post.mu`post_id=1234]`

[markqvist]

Ah, of course, I honestly must've had a bit of tunnel vision here. That's really necessary. As you probably know, the paths themselves cannot contain extra "query string" paramaters, since they are registered and hashed preliminarily on the listener side. But there's no problem in adding them in some kind of syntactical way to the links, and then just including them with the request data in the same way as with the fields. So doing it like that would probably be the most sensible way. Should be pretty easy to implement as well.

[markqvist]

In 1a84e0c019efda22c4da4cfeaf895e51192da451 you can now create variables in links like so:

`[fields and variables variables`:/page/fields.mu`username|two|entitiy_id=4611|action=view]

`[all fields and variables`:/page/fields.mu`*|entitiy_id=4611|action=view]

`[only variables`:/page/fields.mu`entitiy_id=4688|task=something]

I think this should be flexible enough to cover most use-cases, while still being relatively simple to deal with :)

[acehoss]

Awesome! Now I can build a destination detail page for my nomadnet stats generator 😁

[markqvist]

Very nice! I just pushed a few commits that fixes the keyboard navigation for pages with fields as well. It's still a little shoddy, but it works :)

[acehoss]

Something tangential that keeps coming to mind is being able to get the viewport dimensions. You'd have to have some mechanism to send that over from the client, and maybe there's a privacy concern there too. But for laying out tabular data, it would be nice to be able to fit it to the screen.

[markqvist]

Yes, I've been thinking about this myself a bit, but haven't found any good solutions yet. One alternative I thought of was to let the node send a "min-width" header, that tells the client the minimum expected width of the viewport. That way, the client can at least display a message to the user if the viewport is too small, and prompt the user to go into fullscreen mode with Ctrl-G.

[acehoss]

With the link id (and identity if identified), it would be possible to make a width picker page that caches that information for subsequent pages generated in the same session (or later sessions with the same remote identity). Solution-wise it's not as glove-fit as sending the viewport size, but there are no privacy concerns and you don't have to build anything else to make it happen.

[markqvist]

I like all aspects of this solution :)

[markqvist]

Closing issue now since this is already released :)