A long time ago I floated the idea of letting people post interactive programs to lambda+js, which other people could interact with on the site by them being run server-side. I was thinking about that again, particularly how to do it with little or no risk of compromising the site. After pondering about what an appropriate language might look like, I decided it might make more sense to write (or choose) a small virtual machine, and let people post programs that have been compiled into instructions for the VM.

I think it would make the most sense to target simple text-based games first, that is, programs that interact through text input and output. While the VM is being developed and decided on (we might have multiple proposed VMs), people would be able to compile it on their own machines and play with it. This could easily be transformed into a web version with a simple form to enter text commands. We could also have a convention where "[link]" in the text creates a hyperlink which has the same effect as the user entering "link". State could be kept either in the URL or in a hidden form field. Keeping it in the URL would be easier in some ways because it would allow users to easily post their position in a game, allowing for games with two or more players; the disadvantage would be awkwardly long URLs if the required state size is too big.

To prevent denial of service attacks and general nastiness, the VM would have limits both on its memory and the number of instructions it can execute before asking for user input. The VM would not be allowed any access to the operating system other than reading text in and writing text out. So that we don't get haunted by Spectre and friends, and to prevent fingerprinting users who run it on their own machines, everything the VM does would be fully deterministic. There would be no access to the current time, no requesting random numbers from the system, and no operations that could give different results depending on your hardware or VM implementation.

All of this is open to revision. Thoughts?

>idea of letting people post interactive programs
You mean malware and ip grabbers?

P54451
wtf you mean by gaymes?

P54452
based

That sounds fun. Regarding the virtual machine, a simple idea could be a barebone risc-v emulator with a couple instructions added to allow reading/writing input/output text. I once made a rv32IM emulator but I seem to have lost it. I'll try to find some time next week to remake it, if you're interested. It would even be faster than last time since 1. I now know what I would be doing, 2. I won't implement system calls and 3. there probably isn't any need for virtual memory either, since you want a hard limit anyway.

Adding new instructions has the issue that no existing compiler/assembler will know them. So maybe it would be better to implement IO as reading/writing to some memory address? It's not like we will use the full 4GiB address space anyway.

Having some sort of non-volatile memory would be fun too, so as to allow hidden state and multi-user interactions. What could the implementation be though? Have some file mapped to an address range?

If you will run TempleOS stuff on it, then I'm in

P54457
Forgot to post the rv32I (base integer ISA) spec. I don't think the "M" extension (integer multiplication and division) is needed, nor any of the others actually.

P54460
If we're going to go with a preexisting VM ISA, why not go for a JVM bytecode subset? There are a lot of tools for working with JVM bytecode so building an interpreter would be easy and we would already have a compiler in the form of javac.

P54451
what kind of games?

P54468
Because I don't like java. A quick look at the specification makes me think that it is a bit bloated too, which isn't good if admin wants to be sure that there is no bug.
>we would already have a compiler
both gcc and clang can handle risc-v just fine

P54473
>bloat
Then don't implement the bloated parts. It doesn't have to be a complete copy of everything.
>both gcc and clang can handle risc-v just fine
If we want the VM to be based on risc-v and not have to implement all of risc-v then I don't see how that helps. Java has a clear mapping to JVM bytecode, so for example we can be pretty sure that if you don't use a lambda then there won't be InvokeDynamic in the bytecode. GCC and Clang on the other hand could turn an innocent looking loop into a vector instruction equivalent that our VM doesn't implement.

P54529
>Then don't implement the bloated parts.
Then the classic compilers won't always produce bytecode that will run well. That was the original point. And if you are at that, you might as well try something with RISC-V
>GCC and Clang on the other hand could turn an innocent looking loop into a vector instruction equivalent that our VM doesn't implement.
Probably fuck around with optimization/feature flags and it will work. Plus if you are compiling to a derivative of RISC-V the compiler will know to not use instructions that are not available.

P54457
RISC-V sounds good since we'd have the advantage of more compiler support than we'd have with a self-invented ISA.

>I once made a rv32IM emulator but I seem to have lost it. I'll try to find some time next week to remake it, if you're interested.
I am interested. Might try writing one myself but if you know what you're doing you can probably make one that runs faster.

>Adding new instructions has the issue that no existing compiler/assembler will know them. So maybe it would be better to implement IO as reading/writing to some memory address?
Is there an advantage of doing it this way over system calls?

>Having some sort of non-volatile memory would be fun too, so as to allow hidden state and multi-user interactions.
Although having each program come with its own file it can read/write to would be an obvious thing to do, I don't think it would stand up to abuse well. Trolls could just corrupt/wipe the state whenever they felt like it. One idea I had in mind was to have a post button which would attach a file containing the current state of the VM to your post. That way if someone corrupts the state, it only affects the state attached to their own post.

Thinking on it some more, we could just integrate the thing into the existing posting system. We could make it so that if you put a line like this in your comment
P54457> command goes here
then it would start the VM with the state attached to the quoted post, let it read the command as input, and make a post where the output of the VM goes below your comment and the state of the VM is an attached file.

Figuring out how to do
>hidden state
right is something we'll have to think about. I'd like to avoid hiding the state of the VM from users, since that would make it more difficult to make a fully functional copy of the site if it went down. Plus hiding the state from users isn't going to be enough to implement a two-player game with hidden state. Take for example the Battleship game. If the only thing protecting the information about where people had placed their battleships was the VM's state being hidden, then some troll could come along and play out both players' turns for them, revealing where all the ships are, and then post the information in the thread to spoil the game. So you might need some sort of cryptographic solution anyway. It's relatively easy to do for Battleship, especially if you allow inputs to the game to be secret. But other games where you might want to have state that's hidden from both players could be trickier. Something to think about.

P54460
Integer multiplication and division could come up in something as simple as a game played on a 2D grid (if the width isn't a power of 2, otherwise you could just use bit shifts). You could implement it in software, but that would mean using more instructions in a situation where the number of instructions executed is limited. I'm not sure if we need floating point instructions, although someone might want them.

P54451
>no requesting random numbers from the system
Thinking about this some more, this would kill some of the more obvious uses of the system. I don't think providing random numbers would be much of a security risk provided the generator is well-designed.

P54468
The JVM seems higher level than what I'd like. For example, it would have to come with a garbage collector.

P54596
admin your layout of site is nicest chan imo but you better think and implement this game shit well as t seems like a *security hole*

P54606
viewing an image is a security hole for wiggers

P54596
Cool idea, but if you we are playing and exchanging states back and fourth, we gotta consider that a post might have multiple replies and thus multiple differing states. A post might be making a move on a chessboard and placing a guess in a game of battleship, so when another user responds there can will be complications. But it's not a hard problem, either index the outputted states and their respective VM, execute based on a VM and reference the last used state in the game, or (I don't like this one) you could even do a chain of posts as the execution prompt, tho that introduces the likely possibility of another person posting something in /free/ or that thread to correct his actions and edit the chain of states. Or alternatively limit VM execution prompts to 1/post.
Also on hidden states, you are definitely going to need them if you are doing anything like battleship. There are going to be replicability issues if you don't want people to be able to decode the state on the fly.

>random numbers
you could do pseudo-random and contain the side-effects that way.

P54606
What makes it goo about its layout? It's just black, white, blue, and occasionally purple and the layout is carbon-copy standard IB aside from a few differences (thread creation form at the bottom of the page, please fix). Not much variety and complexity, this is something you could encounter on other IBs as well.

P54619
I just checked out Dread's captcha and it can set a cookie that persists across circuits and tabs no problem on the highest security setting. Tho the message says
>403 DoS filter killed your path

P54630
>Or alternatively limit VM execution prompts to 1/post.
If we choose the option of recognizing VM execution prompts within comments (not the only way to do it) then I would certainly limit them to 1/post. Makes things simpler, and we'd need some limit on the number anyway.

>Also on hidden states, you are definitely going to need them if you are doing anything like battleship.
For Battleship, you need hidden input to the program, but you don't need the state when prompting for input to be secret. Each player would choose a passphrase, and the program would encrypt their ship locations with that passphrase. Whenever it is a player's turn, they would have to enter their passphrase, which would allow the VM to decrypt the ship positions so it could call out hits and misses. The issue with this approach is that it only works when every piece of secret data is known by some player. We'd have to come up with something different for games with secrets not known to any player.

>you could do pseudo-random and contain the side-effects that way.
One obvious program we might want to use would be a simple dice roll, like on 4chan's /tg/ and /qst/. In this case it's important that the outcome not be predictable in advance. It would be reasonable to limit requests for random data to 1 request per user input, though, and if a program needed more random data than provided it could use the original data as a seed for a pseudorandom number generator.

wtf has this schizothread devolved into?
im not reading any of these textwalls

P54596
P54630
P54631

>Is there an advantage of doing it this way over system calls?
Not that I know of, except that I understood that you didn't want system calls. Although I guess allowing a few and emulating them properly shouldn't introduce security risks.

>hidden state
I like your idea your idea of attaching the state to posts, though that could be the responsibility of the program. That way, the state would only be attached when needed, and only contain useful data. The emulator could recognise, in addition to stdin (0) and stdout (1), statein (3) and stateout (4) as file descriptors.
Hidden states can be made by encrypting the state with a secret key. Though the secret key being embedded in the program means it can probably be extracted and used by trolls to spoil others' games.
What about implementing a pair of syscalls to encrypt/decrypt a buffer with one of your/the server's keys? That way, secret states could stay secret. Though it doesn't solve the problem that someone making a copy of the site wouldn't be able to decrypt them either.
Ideally, it would use some sort of public key cryptography, so that the same key can be used by players to submit secret inputs.

>Integer multiplication and division
I guess so. It's pretty easy to implement too. I'm not touching anything related to IEEE 754 though.

>random numbers
I second the idea of requesting random data to the OS only once per post. That said, there is no need to require the program implement a pseudorandom number generator. The emulator can do that directly.

With all that, which syscalls are needed?
I can already list:
- read
- write
- getrandom
to which we can add the non-standard
- encrypt
- decrypt (behaviour to be specified)

Does someone know how to tell gcc (or the linker, I guess) to use a specific memory mapping?
By default, it puts the code around 0x10000 and data after that, but I would like it to put the code, let's say, in the 0x0000-0x0fff range and data in 0x1000-0xffff. I know it's possible, since IDEs for micro-controllers and such do it, but I couldn't find any info as to how.

Nevermind, I've found a way https://sourceware.org/binutils/docs/ld/Simple-Example.html. Now the entry point is wrong though. It always points to the start of the .text section, even when it shouldn't

Nevermind, I'm actually stupid. It works now. That said, what's with the "simple example" that doesn't work?

add flash games to your site. we need to play childhood stuff

MINS YMI S Y IN O SOYMI YM IN
YMI OYM YMI O M NSO OY YMI MIN NS
M IN MI M SOYM OYM MIN INSO SO
MI OYM S IN M OYMIN OYMI INS NSOYM OY
I OY IN O NS YMI SOY IN NSO SOY IN YM
N Y S Y SO MIN Y NS SOY OYM SO MI
S MI SOYM OY INS SO OYM YMI YMIN
OY NSO YM OYM NSO OY YMI MIN INS
M MI Y I SOY YM MIN INS SO
INS INS MIN M N OYM MI INS NSO OY
OYMIN MIN INS YMI IN INSOY SOY YM

Just give us a sandboxed scripting language with a limited selection of "syscalls" that allow it to do i/o. Turning this into a Manhattan project means it'll never be done, and you shouldn't be creating unnecessary unpaid work for yourself. Keep it simple and within your means.

Guile is very easy to embed into a C application, and has sandboxing support.
>https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html

Lol your soyware doesnt even have admin ui. Everything has to be done on server's terminal and you are developing another useless feature...

P54757
I thought of another way to handle hidden state. Thinking about these games with hidden information, they would work a lot better if there was a single state that all the players updated instead of each player forking the state when they make a move. That way, you wouldn't have the issue of one of the players trying out multiple moves to extract information he shouldn't be able to access. The main drawback with having a single state updated by all players, that of someone deliberately corrupting the state, is mitigated in this case since the players are authenticating themselves anyway.

So I think a model like this might work well: The program can use a syscall to change the state to a private state. The private state wouldn't be available to the public, and the state file publicly attached to the post would be the last state of the program before it entered private mode. The private state would be stored in a file associated with the particular post number. When other players make their moves, it would update that file. Once all players have made their moves, the program can use all of their passwords combined to decrypt the secret game information and act on it. After doing its thing, the program would erase the encryption key from its memory and re-enter public mode. The state at this point of the program would be attached to the post of the last player to move.

I should point out another way to have state hidden from all players that only requires hidden input: You'd simply need to recruit an additional poster to serve as the "host" of the game. The secret information could be encrypted with the host's key. You might reasonably ask: Why couldn't the board itself serve as the host? Because that model doesn't easily prevent players from trying out multiple moves. So I think if we implement something like this, we should implement the private mode I described earlier. But it should be thought of as a "nice to have" feature, and I probably wouldn't include it in the first version.

>I like your idea your idea of attaching the state to posts, though that could be the responsibility of the program. That way, the state would only be attached when needed, and only contain useful data. The emulator could recognise, in addition to stdin (0) and stdout (1), statein (3) and stateout (4) as file descriptors.

Trimming the state to only what needs to be preserved could be useful. Although the memory mapped file idea might be more natural here, rather than forcing the program to take care of reading and writing the state every time it has to wait for user input.

>With all that, which syscalls are needed?
>I can already list:
>- read
>- write
>- getrandom
>to which we can add the non-standard
>- encrypt
>- decrypt (behaviour to be specified)

A way to halt the program could be useful. For someone running the program offline, it would be good to have a graceful way to exit, and when running the program on lambdaplusjs, a program that has halted would not have its state attached to the post, only any output it created.

What else should we consider? If we add a way to do secret input, it would make sense to have a way to do secret output, which only would be shown to the current player. Perhaps this could be done with an interstitial screen after posting, whereas public output would be shown along the user's post. It might also make sense to have a way to interact with the program without posting anything. Interactions done this way would not save any state, and we'd probably have to decrease the limit on the number of instructions that can be executed, since it wouldn't be subject to the cooldown limits imposted on posting. Or I could make a separate cooldown system for it. Yet another idea: let the program read (and perhaps write) files attached to the participant's post.

Whatever we think of, we should probably aim for a barebones system first and implement frills later if desired.

P54985
A lot of the work here is going to be in designing and implementing the user interface to this thing. I don't think using an existing scripting sandbox really reduces the workload that much. Assuming we go the RISC-V route, the instruction set we're talking about implementing is very small. And it comes with some advantages:
- users aren't forced into using a particular programming language
- it will be possible to write programs in a manner that guarantees they will not exceed their allotted computation time
- a simpler sandbox is likely more secure
But obviously keeping the initial implementation as simple as possible is a good idea. We can still talk about ways we might extend it, and probably should, since we don't want to accidentally design the initial system in a way that blocks future extensions.

Why is this board called lambda+js when there is no js?

P55154

because its fucking cucked and need be shutdown with an immediate effect

P55701
true, move it to /free fo thee

P54451
nobody wants to run your code to run some special snowflake yet another VM
you are a website
you should not even be able to do CSS
this is why wigger tech is a shithole, you want to make what should have existed in 1990: a way to run code without it having access to all your files and shit. nobody is gonna check that you didnt backdoor your C crap with obscure UB just so they can run a vm / language nobody uses
inb4 muh this n that linux/bsd security mechanisms that nobody uses nor audits which only solve half the problem etc
this is what js in the browser is supposed to be but obviously it doesnt work since its made by absolute retards such as w3c

At times, contributions made by active users on this site are swiftly moved to /spam/. For instance, P58413 was published at 17:40:37 and moved at 17:40:46, so it took you less than 9 seconds to decide to move it. However, there are times when a post that is destined to be moved may sit unmoved for hours before you move it.

What is the reason for this delay?

P59116
There is a bot admin which automatically sorts some things, but not everything

SHUT THE SITE DOWN NOW FAGMIN!!!

P59116

I can't see the reason posts are moved from one place to another. Something from /free/ might end up in /misc/ or vise-versa, then on to another place. It seems to be completely random. I'm going to start including geolocation trackers on my posts.

P54454

This is the same person that can't install a favicon, or add code tags. Chance of a VM that people program approaching zero.