Oddbean

Right now pear runtime is vanilla JavaScript. But they are building things to make integration easier. And if you just use it for the connection you can always simply use it to then establish an SSH tunnel or whatever to do any other kind of communication necessary. Not sure how integration would work, but the Pear Runtime platform is still very fresh, only released in Feb of this year. So no other languages yet but the community building with it is picking up momentum quickly. It’s largely because people are seeing it just work. I literally have been connecting *tons* of services between devices with this and Holesail just dropped a mobile app. I already have a setup to run LLMs off my Linux with the ability to upload files and it’s crazy how fast it all is. I’ve got a video waiting to publish on unlisted YouTube right now. Really short just showing how it works. I’ll post here when we publish

We should build a consortium to recode it in native Kotlin and create a little library for it. Then all apps could use it. I just don't know where to start, holesail has a web of dependencies and I don't really know what each thing does.

watch their tutorials https://youtube.com/@Pears_p2p they are currently working on massive improvements to their mobile tooling and tutorials and example code, this is their current main example https://github.com/holepunchto/pear-expo-hello-world in keet.io there is a link to the community room on the profile page and there is a number of dev rooms https://github.com/gasolin/awesome-pears/blob/main/keet_rooms.md 🍐 Pear Development - pear development related discussion (Official) pear://keet/yryzix4muu85ocwke9njhfppkyjkkrhy15gdyam137jxhtu4ei6y43npudeidy49kiisp9mghefgfg4rcp7iww881sq5dm13syjuim7awr Bare Developement 🐻 (new) (invite expires on 2024/7/7 0:38 UTC) pear://keet/yrbooziif9ryfdxm5o665bpx7rgcrophs8o4sarufmrgfa16fiy1mjiwahgyfx3qkyk4pahkmnj8wc1wmmanumf7zikq8mhp4jh1honzo1n68nmg Pear Baby Room for new devs(invite expires on 2024/7/7 0:39 UTC) pear://keet/yrb9wwk87cqhq7x7wc3oub4e5efdiobjf4sdoxnd3s4k694oh4sd1wogfu8hi4ky6eztrz64j4s8tc6r1zjsodboibsd9usepmixe6mpr9yq8nmg

This could be possible (though would require some work), you need to embed bare runtime in your java/kotlin application and run holesail-client and holesail-server on it. It is a tedious and undocumented process atm, but holepunch team is working on new mobile development kit, hopefully that will resolve this and make development easier

Hey! Very glad to learn you're on Nostr. I work on solid state interpreter personal servers, and hole-punching is a task we'll be looking into very soon as we get deeper into peer-to-peer aspects.

Our blog posts and documentation are coming online a little more every week, and a good explanation of the SSI is much-needed topic, but I'll give a brief taste here. SSIs are a novel computing model and therefore are still tough to describe at first... An SSI is a purely functional, single-level store VM and programming environment. Rather than "operating system", think "single operating function". There is a single, frozen top-level function that takes as it's input the "computer's" state as an append-only event log. The net result of that is you have a highly portable SINGLE value that describes the entire state of a computer's storage AND active computation with zero external dependencies. What I mean by "single level store" is that the Operating Function makes no distinction between memory and disk, such that you can take an entire running computer, turn it off instantly, put its representation on a USB drive and ship it across the world, plug it in and start it and it'll be running exactly as it was. (This has happy implications for "durable execution" style cloud services, as well as ridiculous peace of mind for local, personal compute). You get this persistence for free in the programming language: there's no DB interface to import and rely on. The whole persisted state of the VM and every running application is a single closure. Other similar systems (like Urbit, introduced in the paper below) have very limited storage capacity, while our system can easily handle terabytes of data. Which means that an individual running a VM like this in the cloud can be their own S3-style static file host. Or a network of similar instances can act as a replacement for something like IPFS. okay well I've rambled far too long now and only scratched the surface, but I'll leave you with: our "VM" is stupidly easy to run. It's not like installing Linux. You just start the binary and it's going. So an exciting bit of low hanging fruit in my mind is making it trivially easy for every nostr user to have their own personal relay, either on their own hardware or in the cloud and optionally behind a proxy to preserve IP privacy. The whitepaper that originally introduced the concept of the SSI: https://media.urbit.org/whitepaper.pdf We've got new posts and podcast episodes coming every week: https://blog.vaporware.network My company's brief landing page: https://vaporware.network I should also mention that all our work is free and open source and all the code that is analogous to regular systems' "compiler binaries" is actually human-readable, so our VM 's entire stack from hardware interaction to userspace applications doesn't ever ask you to trust, but instead to verify. Happy to answer any questions!

This seems like a crazy awesome idea in theory but that it could run into a million problems in practice. How much setup is needed to run this on any random machine and how do you boot into it exactly? I might actually like to chat with you out of band about this just to get a better idea of things if you have some time. Mind if I DM?

Naming conventions in this are all over the place. Making it sound kinda ridiculous, imo. Ships, and plunder, Sire, all make it more confusing, not less, imo. No offense, just trying to give honest feedback.

Maaaan did you guys put a damn token in this thing? If that’s what this is, I don’t think you realize how much this ensures the project has no future. And just how quickly it’s going to turn off a *ton* of people up here, all while ruining the incentives of the very project. Am I reading that right? https://i.nostr.build/dwBrY.jpg

There are no tokens in our stack or dependencies on blockchains of any variety, including Bitcoin. The token stuff you see on that landing page was an early idea for handling trustless software versioning and provenance. We aren't working on that now; building core OS primitives currently.

As a cofounder of the company I commit this note to my personal relay and many others: The core OS primitives that we build are now and will continue forever to be trustless, permissionless, open source, and not dependent upon tokens to operate. Given that it is FOSS, I can't determine what other people will build on top of the system - nor do I have any interest in making it possible for my opinions and principles to dictate what others can do with my software.

To elaborate a bit, since you're asking about it: we were not going to launch a token. We experimented with attaching software to ethereum NFTs such that purchase of an NFT meant the author of the software would distribute the source code to you. And reselling the NFT meant the new owner would receive the software (statefully! Meaning if you had a "Pokemon" app containing a highly trained Pikachu and you sold that app to someone else, he would have that trained Pikachu now.) The app data wasn't stored onchain, nor was the source code, both of those were local to the VM and transferred to the new owner as a serialized value. just the ownership record was stored onchain via NFT. ...but as I said, that was an early demo to prove some things about code and state distribution. There's nothing in our current code that has anything to do with blockchains. If two people can peer with eachother, they can distribute software (or any other arbitrary digital content) to eachother in an uncensorable manner. Pirate app stores from the future!

Completely agreed! The fuller story on our current messaging is that current users and developers of the Urbit platform are most familiar with the technologies involved in our stack, and our messaging is mostly directed pretty narrowly at them. We absolutely owe a more readily understandable explanation to a wider audience and we're working on that. (As well as building demos for a general audience. We've already built an S3-style service that was shared with a small beta testing group). We are extremely busy and are trying to direct our energies where they are most fruitful, as I'm sure you understand :)

I’m keeping the DM inbox warm for you. To answer some of the questions you asked here now: - How much setup is needed: exactly zero. There are a couple different runtimes in the works right now, but with the C runtime it’s literally just getting a hold of the compiled binary and running it. There are zero host machine dependencies - How do you boot into it: **for now** “you don’t” (boot INTO it). You interact with it via the CLI or more robustly via the browser (either on the host machine or over HTTP from a remote machine, if you’re using the web server aspects). For the moment, the easiest way to create UIs is via standard web stack, and we have a number of examples of that (group chat, image board, S3 bucket, a MUD with randomly-generated maps, etc. etc.) Working with native graphics is a consideration, but we’re more interested ultimately with running our OS natively on devices - starting off something like an Android fork and going from there (the @daylightco is a good mental model. basically a new device type category).

You’re thinking of HolePunch, not Holesail. Holesail is built on the same stack as Keet is, but it’s a completely separate project. HolePunch is the company behind the development of all of this. The naming conventions can be super confusing and there’s basically like 4 of them 🤣. Thats why I just refer to it as the pear stack now.