You are reading content from Scuttlebutt
@xj9
Created a git repo 友/os
@xj9
Did a git update
@xj9
Did a git update
-Add license
@xj9
Did a git update
@xj9
Voted this
@xj9
Voted this
@xj9
Voted this
@xj9
Did a git update
-git-annex in carlos@momo-4.local:~/src/source.heropunch.io/tomo/os
-update
-update
-update
-branch created
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
@xj9
Changed something in about
{
  "type": "about",
  "about": "%1BtG8h6Oh6uI7kjnZkvK20wqLrCZlbbFxrZ3e6zRWro=.sha256",
  "name": "友/tomo"
}
@xj9
Did a git update
-Add 'hardware/nomad/' from commit '3fb31c43a72019741f342cc9f90c583bcd66d2bd'
-Add 'hardware/cybredeck/' from commit '73209d142fbc276f0e907fe183550c997a30a78a'
-target link, add comma
-initial commit
-Update README.md
-Update README.md
-Update README.md
-add icon
-Update README.md
-Add new file
-Add license
@xj9
Did a git update
-update README.md
@xj9
Did a git update
-add getting started section
@xj9
Created a git issue

dbus-broker

https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

https://news.ycombinator.com/item?id=15081349

@xj9
Created a git issue

real-time audio

@xj9
Created a git issue

support restricted clearnet gateways

machine pairing requires a handshake that can only be done via clearnet. a limited gateway (port 22) can facilitate this use case without forcing the user to reveal themselves.

gateways must be trusted explicitly. bundle trusted community keys.

@xj9
Created a git issue

bamboo enclosure?

https://www.adafruit.com/product/2475

http://colorfabb.com/woodfill

@xj9
Did a git update
-add lightning talk slides
@xj9
Did a git update
-be a little bit more polite
@xj9
Did a git update
@xj9
Did a git update
@xj9
Created a git issue

publish design docs

i've been taking notes about the architecture of the os and some of the applications that i'm more excited about building (musicwithfriends owo). i also have a collection of mockups that i'm slowly converting into digital documents using pencil. i posted a draft of the tracker ui mockup, but i probably need to read up a bit more on using git-annex because i can't open it now. i had some fs corruption issues recently, so i might just be running into that problem again. ¯_(ツ)_/¯

@xj9
Created a git issue

document git-annex usage

a quick rundown

  • setup
  • commands that you use to add/dl/update assets via ipfs
@xj9
Created a git issue

rfc - elixir/python-like syntax for clojure

@dtluna has requested that we develop a tool that transpiles a python/elixir-like language to clojure in order to create a more familiar development experience.

i am perfectly comfortable working in clojure directly, but i do see the appeal of having "beautiful" syntax to work with and i've see it work magic in the elixir community.

a few bits of syntax that i find handy are expressions and implied returns

let val = if (cond) {
  1
} else {
  2
}

destructuring/pattern matching and immutable binding. i enjoy significant whitespace tbh.

we can't really break from clojure semantics, but there are some interesting things we can do to make the lang a bit more powerful like TCO. clojure has (recur), which we can inject into the function body under certain circumstances. 👌

@xj9
Did a git update
-port gitlab-ci to local deploy script
@xj9
Created a git issue

heropunch.io deploy script

build and deploy the manual in one step

@xj9
Re: %seCSbr6c/
@xj9
Did a git update
-update join.md
@xj9
Did a git update
-add alpha to favicon.ico
@xj9
Re: %fGgrXLfto

i think this is going to derail us too much. perhaps rust is the tool we are looking for? there's already a community of developers, a small, but growing, ecosystem of very safe code. it isn't quite as functional as i would like, but the whole idea of CONCURRENCY WITHOUT FEAR checks that all important box. the syntax is familiar and the borrow checker enforces a certain amount of correctness which i find appealing.

i really wanted to make lisp machines, but i do realize that language syntax matters for adoption and i would like to make tomo and relax fun, accessible tools that developers will enjoy using.

@xj9
Did a git update
-update README.md, better project overview and introduction
-Add 'src/rust-multihash/' from commit 'e876741af1dd7b97a347f29dc67ac5d905b306c3'
-move source files into src/
-Rename multihash::HashTypes -> multihash::HashType
-Fix doctest
-Update authors
-Merge pull request #2 from eminence/priv_merge
-Remove #[feature(convert)], add .travis.yml
-Merge branch 'eminence-docfixes'
-Merge branch 'hashtypes' into priv_merge
@xj9
Re: %fGgrXLfto

the most important language features i'm looking for are:

  1. good concurrency primitives (little-to-no footguns)
  2. native build output
  3. functional programming
  4. simple ffi

clojure(+ferret) and rust both check the same boxes. rust even has hygienic macros and syntax extensions these days. probably not quite as powerful as lisp macros, but it isn't like that ability would be completely lost.

i'm not really married to one lang over another. i'm trying to strike a balance between performance, productivity, and safety. the goal here is to make it easy to develop applications that sip energy. easy access to concurrency enables developers to spread their workload across as many cores as possible. in a mobile context, this allows the OS to keep more cores in a low energy state while providing sufficient throughput to enable rich interactive applications.

@xj9
Re: %fGgrXLfto

i like your thinking @nanomonkey! much of the tomo/relax architecture is built around message passing, so it would be easy to hook a high-level scripting interface directly into the guts of your system. i really like the idea of creating powerful interfaces like this to give users deep control over their system, but the line between application and customization gets blurry really fast. so really, you need something that can cover the full range scripting and building basic applications. i specifically want to avoid web tech (javascript), but things like python or guile could be a really good fit.

@xj9
Re: %fGgrXLfto

actually, maybe joxa or lfe would be interesting. BEAM has all of the hot reloading, live hacking, and concurrency stuff you could possibly ask for. users can even elect to use elixir or erlang syntax and be fully interoperable with all of the other shit.

@xj9
Created a git issue

license for sub-projects

some external projects may not be licensed GPL, so the question is, do we want to infect everything or explicitly note that our contributions are under the original license?

@xj9
Created a git issue

relax/ui

functional-reactive gui programming based on rust-efl. taking inspiration from elm, react native, and vue. react can be pretty verbose, so i would like to tackle that area especially. i find vue to be a very productive environment for building complex user interfaces (my day job at CityGro). angular 2 is built around some really great concepts as well. observables, i think, are particularly useful for this domain.

one nice think about building on the efl is that we can access all of the nice themeing capabilities even though we are using a very different method for constructing our interfaces. additionally, this creates an important separation between the logic and layout of an application and the aesthetic and artistic aspects. obviously these are connected, but this separation also helps developers create applications that share a cohesive look. users can opt to change the look of their environment and it will be applied across their entire system!

@xj9
Created a git issue

alpine build toolchain

友/tomo is designed to be an overlay on top of vanilla Alpine Linux. we differentiate ourselves by adding new features rather than by modifying our foundation. any bugs that exist in Alpine Linux should be fixed upstream. we maintain:

  1. this source tree
  2. an apk repo that contains 友/os-specific packages

so, we need some tools to allow us to build against arbitrary versions of alpine for testing and development. this goes a little bit beyond the provisioning/scheduling stuff that grid does, but it will be
a good way to see how useful it can be as a development tool.

@xj9
Re: %8KAr6ZdVc

there are two ways we can expect to construct graphical applications on 友/tomo:

  1. native rust applications
  2. BEAM applications

relax/ui will be constructed using idiomatic rust constructs and some syntax extensions for ergonomics. this will be the first area that we focus on. however, it would be nice to construct this high level interface in a way that allows OTP applications to update the UI state using the same kind of message passing api that you would expect from any other module.

one way to tackle this would be to create a rust library that translates erlang terms into the a the high-level component representation mentioned above and compiles them into native rust calls at runtime. this would could be an abstraction of the macro code which does the same for native rust expressions at compile time. of course, this creates some overhead, but it can be minimized by using BEAM FFI and is probably trivial in comparison to rendering and other computations happening in the application.

this decoupling also creates a nice way to do native app development in REPL environment with hot reloading. the native bits only have to be restarted if you change something in rust world, but your application state for BEAM applications would live inside of the VM. after you reload a module, you simply emit the new state to relax/ui and the new scene is rendered on your screen.

@xj9
Re: %fGgrXLfto

i'm liking where this rust + BEAM line of thinking is taking me, i think i'm going to run with it. particularly, i like that we can have the lisp machine interaction model without forcing users into a specific language. i mean, they are limited to things that run on BEAM, but they do have some choices that don't create any additional work for us from a support perspective.

thanks for the feedback!

@xj9
Did a git update
-create project stubs
-rename grid/pkgs => gridpkgs, update README.md
-laminar 0.4 snapshot
-add src/README.md
@xj9
Re: %yvgorcG/q
@xj9
Created a git issue

mesh ingress/egress

the core application routing layer inside of 友/os is i2p (provided by router). this ensures that applications are isolated from the clearnet by default. users may allow individual devices to access clearnet resources via ingress and egress resources.

ingress options:

  • host
  • vpn

egress options

  • tor
  • host
  • vpn
@xj9
Did a git update
-Merge commit '46c85a76bec56c57d05277fd56570d0829f8553a' as 'lib/src/lsmbpt'
-Squashed 'lib/src/lsmbpt/' content from commit b7ac51d
@xj9
Created a git issue

[lib] [lsmbpt] get() only searches the in-memory B-tree

The implementation of get() only checks the memory tree, not the disk tree.

@xj9
Re: %H8zbfKje0

http://localhost:7718/%251BtG8h6Oh6uI7kjnZkvK20wqLrCZlbbFxrZ3e6zRWro%3D.sha256/blob/06a2654a7a066f6bac2ef26018cd0583b87eee2f/lib/src/lsmbpt/src/lib.rs#L88

@xj9
Did a git update
-Merge commit 'e6f3c15c1fbbd2e5e1a224dbb5d7fb700d178210' into latest
-Squashed 'lib/src/lsmbpt/' changes from b7ac51d..63b9d02
@xj9
Re: %H8zbfKje0

http://localhost:7718/%251BtG8h6Oh6uI7kjnZkvK20wqLrCZlbbFxrZ3e6zRWro%3D.sha256/tree/1de45a4364927d1ce78e862c62cbd40bc9e51b79

pulled commits from a fork that might fix this

@xj9
Created a git issue

[tracker] window management

  • persist window layout
    • layout changes
    • app launch log
  • automatic tiling

inspiration

data-driven interfaces, distributed activity log:

  • time
  • location
  • related data
    • events
    • calendar
    • tasks
    • notes
  • tags
  • indexed metadata
@xj9
Did a git update
-add hackr stub
-reorganize manual
@xj9
Did a git update
@xj9
Did a git update
-remove extraneous i2p application code
-i2pd -> router, laminar -> hrunner
@xj9
Did a git update
-some extern declarations, rust interfaces
@xj9
Re: %w2LkE7LMt

activity-centric desktop home screen concept

home.png

@xj9
Created a git issue

[keychain] syncable, sharable, secret storage

  • each secret is a separate encrypted blob
  • secrets can have multiple recipients

ok so why share secrets? well, if you have some data stored in ipfs for example you could share it privately with n friends. if this is something that changes over time you could also revoke access by changing they key and removing one or more users from the recipients list. of course, this doesn't prevent them from accessing previous versions, but you also couldn't stop them from making copies in the first place.

the idea is to make it as easy as possible for users to share encrypted data. this also works for auth tokens like passwords to shared accounts. you can rotate the password periodically without introducing any additional overhead of telling everyone what the new password is and whatnot.

@xj9
Created a git issue

[grid] virtualization

i don't think hw virt is the best option for general purpose applications (especially for mobile devices), but i do think it is important to have good sandboxing options everywhere you go. preferably using technology that scales from very small to very large systems. virtualization in a general sense has a lot of very useful applications, so i don't think its fair to say that os virt is superior the way the people at joyent would have you think.

the balance i want to strike here is a tool that balances access to lightweight os virtualization for sandboxing and shipping applications and high-performance hardware virtualization for emulation/mobile dev.

@xj9
Re: %cKtEeG37d

https://github.com/msantos/erlang-libvirt

https://github.com/msantos/verx

libvirt fits the niche i'm looking at pretty well, but i'd like to have a look around before i commit to it.

@xj9
Re: %8KAr6ZdVc

i'm working through creating a rust binding to EFL which will serve as the rendering backend for relax.

i've decided to ditch the idea of developing uis in rust, working inside of BEAM will be a much nicer experience (live reload and all that).

one way to tackle this would be to create a rust library that translates erlang terms into the a the high-level component representation mentioned above and compiles them into native rust calls at runtime. of course, this creates some overhead, but it can be minimized by using BEAM FFI and is probably trivial in comparison to rendering and other computations happening in the application.

@xj9
Did a git update
-add image server scripts, fix links
@xj9
Did a git update
-better onboarding docs
@xj9
Did a git update
-WIP
@xj9
Did a git update
@xj9
Did a git update
-update readme again
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
-WIP
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
@xj9
Did a git update
@xj9
Changed something in about
{
  "type": "about",
  "about": "%1BtG8h6Oh6uI7kjnZkvK20wqLrCZlbbFxrZ3e6zRWro=.sha256",
  "name": "heropunch"
}
@xj9
Did a git update
-initial commit
@xj9
Changed something in about
{
  "type": "about",
  "about": "%1BtG8h6Oh6uI7kjnZkvK20wqLrCZlbbFxrZ3e6zRWro=.sha256",
  "name": "友/tomo"
}
@xj9
Re: %PTb9H1R98

i created a package mirror at https://pkgs.heropunch.io

some time next week i'm going to fork the postmarket bootstrap repo and write a few APKBUILD scripts:

  • sbot
  • patchfoo
  • ipfs
  • couchdb
  • e21
  • git-ssb

the image will be published over ipfs and linked to from https://www.heropunch.io/%E5%8F%8B/os which i will also have to clean up for the release day.

@xj9
Changed something in about
{
  "type": "about",
  "about": "%1BtG8h6Oh6uI7kjnZkvK20wqLrCZlbbFxrZ3e6zRWro=.sha256",
  "name": "友/os"
}
@xj9
Created a git issue

[aports] [tomo-base] hosts zero package

null route domains that are hostile to user privacy

http://someonewhocares.org/hosts/zero/

@xj9
Created a git issue

[aports] openvpn config files for reputable vpn services

https://github.com/haugene/docker-transmission-openvpn/tree/dev/openvpn

@xj9
Re: %cKtEeG37d

https://containersummit.io/events/sf-2015/videos/going-container-native

@xj9
Created a git issue

[aports] alternate coreutils replaces gnu coreutils

  • suckless
  • bsd
  • toybox

i'm leaning towards suckless, but the bsd tools are nice too

@xj9
Did a git update
-add ethical design badge
@xj9
Created a git issue

[aports] enlightenment packages

  • efl
  • vanilla enlightenment desktop

the desktop package will eventually be replaced by tracker, but it would be nice to have a (temporary) graphical environment to work with in the interim.

@xj9
Created a git issue

[installer] tomo recovery image

i am envisioning a mobile inspired installation process that revolves around "flashing" disk images to devices using a tool like tomo/bootstrap or a recovery image. this method makes it easy to test and swap os versions and provides a higher level of consistency when installing particular os versions.

the base os image is always read-only. each session is started in a private overlay filesystem that allows them to mutate their view of the system without compromising integrity.

the update architecture is copied from CoreOS. in short, you have two system partitions, one active and one spare. when you get a new os image the spare partition is flashed and selected as the active partition for the next boot. if there is a problem, the last known good state hasn't been overwritten yet and can be used to reinitialize the system until a new fixed image can be downloaded.

tomo recovery will include utilities for downloading images and other update metadata over secure p2p channels.

@xj9
Re: %cKtEeG37d

tomo/bootstrap used qemu to virtualize mobile hardware. this tool is forked from pmbootstrap (postmarketos is our upstream).

as for application packaging and isolation the simplest solution (imo) is appimage. we will need to explore options for sandboxing and asking for permissions, but the fat binary architecture gives us the most flexibility. there are a few other options that have their own opinions about how to approach this problem, but grid throws in a few more conditions that will require special consideration.

@xj9
Re: %dBSKSywRx

going nuklear with x0

@xj9
Created a git issue

[bootstrap] pmbootstrap.py does not work with the hardened Alpine kernel on host system

this appears to be a specific issue with the way pmbootstrap.py interacts with qemu. there is evidence to suggest that you actually can use qemu on linux-hardened.

https://github.com/postmarketOS/pmbootstrap/issues/107

https://forums.gentoo.org/viewtopic-t-973808-start-0.html

https://blog.skunkw0rks.io/blog/2017/04/01/alpine-linux-as-a-kvm-host/

https://wiki.alpinelinux.org/wiki/KVM

https://github.com/BastienM/alpine-kvm

since we don't really care about compatibility with other distros, it might be a good idea to integrate with some of the native alpine tooling for generating os images.

https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage

@xj9
Created a git issue

[bootstrap] apk repo for tomo development toolkit

echo "@tomo-dev https://some.pkg.server.heropunch.io/tomo/dev" >> /etc/apk/repositories
apk add bootstrap@tomo-dev

install all of the latest tools for developing tomo applications!

see also

%PTb9H1R...

@xj9
Created a git issue

[grid] distribute applications images as .iso files?

this idea is inspired by PLEROMA.ISO, but i think it might hold some promise. this is similar to the idea of .dmg files in macOS, but rather than copy some stuff out of the image, we can run the application from the image itself.

of course, there are other formats that are also suited for distributing applications images. something like archivemount could be used to make compressed images readable without decompressing them on-disk.

it really depends on what the goals are. PLEROMA.ISO is a sort of uni-kernel-style approach to distributing applications, but you might want to run more than one application on a host. in that case, do you really want to ship all of the kernel stuff with your app?

@xj9
Re: %M86OkoP55

proper link ref %0wLfmTg...

@xj9
Created a git issue

[hypermesh] peer-to-peer software defined networking

a small daemon written in elixir that speaks the cjdns admin protocol. hypermesh integrates wish grid to provide encrypted overlay networking that routes traffic between a user's hosts and their peers.

@xj9
Re: %ekXmwSCfC

%mmxYY36...

@xj9
Re: %sR9bDl1Jg
@xj9
Re: %GG21d4+fX
@xj9
Re: %PTb9H1R98

%fUvVGC2... %fMafe2p...

@xj9
Re: %ykNOCFFZX

respec pls or WTFPL

@xj9
Re: %rvO6h7EWW
@xj9
Re: %H8zbfKje0
@xj9
Created a git issue

[bootstrap] pmbootstrap.py depends on gnu coreutils

bootstrap should either

  1. explicitly depend on the default coreutils that ship with tomo %T72mdip...
  2. use a subset of options that work between gnu/busybox/suckless coreutils
@xj9
Created a git issue

[IOT] securely link embedded devices to user mesh hosts

tomo's crypto-mesh overlay is too cpu intensive to run directly on modern embedded devices. seamless, secure IOT is an explicit goal for tomo, so this topic warrants some investigation. some known options that should be explored include:

  1. run a traditional AP/wireless gateway that acts as a secure MQTT broker
  2. 802.11s + WolfSSL
  3. BATMAN + WolfSSL

any implementation MUST support:

  1. link-layer security
  2. mutual authentication between endpoints
  3. e2e encryption

tomo/bootstrap will need to support key flashing/association in the IOT device setup workflow.

@xj9
Re: %F+OQl51H+
@xj9
Created a git issue

[IOT] securely link embedded devices to user mesh hosts

tomo's crypto-mesh overlay is too cpu intensive to run directly on modern embedded devices. seamless, secure IOT is an explicit goal for tomo, so this topic warrants some investigation. some known options that should be explored include:

  1. run a traditional AP/wireless gateway that acts as a secure MQTT broker
  2. 802.11s + WolfSSL
  3. BATMAN + WolfSSL

any implementation MUST support:

  1. link-layer security
  2. mutual authentication between endpoints
  3. e2e encryption

tomo/bootstrap will need to support key flashing/association in the IOT device setup workflow.

@xj9
Re: %M86OkoP55

@clackers

i wrote a mini appimage clone in ~35 lines of bash that you might like. %PqoIvVl...

it is a proof of concept of course, but the idea was to prove to myself that the basic functionality that you get from AppImage is easy to achieve with a little shell script glue.

the next bit i'm thinking about is app verification, which i think can be accomplished by using ssb feeds to publish blob hashes. currently, blobs are limited in size, but i'm working on getting past that limitation.

grid doesn't care what you put inside of the application image. so, it would be trivial to package a nixos derivation inside a grid image. there's lots of flexibility here because i can't really say what the best solution is. i really like what nixos is doing, but i also value the relative simplicity of something like APKBUILD.

@xj9
Re: %fGgrXLfto
@xj9
Re: %fGgrXLfto

relax is a scheme distribution geared towards building native peer-to-peer applications. this distribution is largely a collection of language extensions that make scheme feel more familiar and encourage happy patterns. by leveraging chicken scheme compiler and syntax macros, we can generate very efficient assembly from high-level source code. planned improvements, such as hindley-milner type checking, will allow for further optimizations. relax language extensions are defined strictly in terms of R5RS, but parts of the foundation libraries may depend on chicken scheme-specific apis. at the moment, this appears to be a good balance between portability and agility.

efficiently utilizing multiple cores is one of the most critical aspects of mobile performance. nvidia and others have observed this effect in practice: (pardon the ipfs link, this pdf is too large to attach as a blob)

The dynamic power consumption of each core is proportional to the operating frequency and to
the square of the operating voltage. Due to the exponential relationship between power and
voltage, the dual core CPU consumes lower power than a single core CPU for the same
workload. The figure below shows how a dual core Cortex-A9 CPU will consume only 60% of
the power consumed by a single core Cortex-A8 for the same task.

the other side of that coin is writing software that can efficiently utilize all available cores. relax encourages patterns based on erlang/otp and clojure that enable automatic concurrency, easy debugging, and strong fault tolerance. as many of us have noticed with the release of #manyverse #p2p applications can be big drain on your battery. cryptography and networking an be quite energy intensive. for that reason, among others, i feel the need to take a holistic approach to future networking by integrating the core protocols into the application runtime and operating system. all of the individual components are portable, but the eventual goal is full integration with a handful of open hardware platforms.

one of the goals of the genode project is to provide a set of common interfaces for building micro-kernel based operating systems. combined with R5RS and other hardware and software standards, we have something that looks a lot like the web stack in terms of standardization, with a much keener focus on the unique challenges of mobile computing. most of these ideas are not mine, but they seem to fit well together with a very minimal amount of code. the goal is something like a browser, that a motivated community can maintain successfully. in contrast with web browsers, outside of Chrome, Firefox, Edge, and Safari and their forks you aren't going to find anything that can keep up on web standards and performance.

@xj9
Re: %fGgrXLfto

relax is sort of an ad-hoc thing right now, but i'll spend time standardizing and documenting my ideas as they evolve.

@xj9
Re: %fGgrXLfto

a few comments on BEAM:

i've been running pleroma on an rpi for a few months now. this is a pretty typical load:

Screen Shot 2018-10-04 at 9.17.52 AM.png

the full service list includes: postgresql, pleroma (beam), privoxy, cjdns, and tor. this isn't too bad if you look at this as a single-purpose device, but that doesn't include the client and its only one application + supporting daemons. CPU utilization is mostly even across cores (as expected), but the combination of startup lag and memory usage (our biggest limitation with embedded ARM SoCs) has pushed me to find a native solution that approximates the architecture of erlang/otp without some of the downsides.

@xj9
Re: %fGgrXLfto

@alanz oops probably should have added "RFC draft" title. it would be sweet if i could rename the issue. c'est la vie i suppose

@xj9
Created a git issue

[RFC] relax scheme

let's continue this train of thought in a new thread. read the first draft here.

scheme is intentionally minimal, but there are a lot of eggs that we can use to extend the language to provide a more comfortable environment. clojure.core and clojure.core.async can also serve as sources of inspiration for relax-specific standard library and language extensions.

@xj9
Re: %fGgrXLfto
Join Scuttlebutt now