LogosLab: A learning experience for the home or classroom

[arseniy]

LogosLab

A learning experience for the home or classroom

Background

We can use NixOS and a standard set of inexpensive devices to package both software and hardware, alongside instructions, into a self-guided experience which teaches technology, programming, and more, all while using the Logos stack to connect with other students and earn rewards.

Uses open-source hardware based on FOSS principles ( e.g. https://pine64.org )

Product

Example kit includes:

• Nix-compatible Laptop or mini-PC (no OS)
• Nix-compatible phone (no OS)
• Nix-compatible e-ink tablet, pre-installed with NixOS and an app called TechTree
  • the tablet has no networking ports, bluetooth, or WiFi
  • only NFC
• Keycard + Shell
• Printed Logos literature
• Branded Swag
• printed Getting Started instructions:
  • setup Keycard + Shell
  • create profile in TechTree with Keycard

TechTree:

• Prior art: https://speedrunethereum.com/
• Players progress through a dependency graph of lessons to learn, install, run, and build on the Logos stack, unlocking rewards along the way
  • on the e-reader it’s basically an interactive instruction manual
• First stage: Install NixOS on laptop and mobile
• Second stage: Install and run nwaku, nimbus, nim-codex
• Third stage: generate a transaction to a specific smart contract and sign with keycard to unlock the next stage
• Third stage: follow instructions to write scripts that “gather” pieces of a puzzle from each network
  • The different pieces were derived from the signing address and some secret value, such that if all the pieces are gathered together, one could prove that hashing with the signing address results in the secret value
  • e.g. find a specific event for a smart contract, listen to a topic on Waku, get a cid from codex
• Fourth stage: Install Status and use the gathered key to unlock access to an exclusive community with other players
• From there, lessons continue depending on which tracts players choose

Misc

LogosLab in different settings

Home

The above product description assumes an individual purchasing a kit and playing with it at home. There’s not much guarantee it will be used at all, and in general it might be hard for someone, student or guardian of a student, to justify spending ~$600 for a phone and laptop (based on prices from pine64, and I doubt those are even fully capable of running every feature of our stack) for something that might not be used much. I do think there are some potential customers for this, but in terms of reaching as many people as possible it may not be as effective.

Classroom

An organization like a school (or homeschooling pod, university, etc) maybe buys several for a classroom, and maybe students can “borrow” them for the duration of a course and give them back.

In this case, it makes sense to expand the software to be able to store and retrieve all student’s data using just keycard or other method of authentication. So even if a student finishes a course, or leaves, or is away from the classroom, lessons can be resumed anywhere on any device (it’ll be up to them to get the logos stack running on devices that were not purchased as part of LogosLab).

But what if, in place of or alongside of, the portable devices, there are stationary terminals in form factors similar to arcade cabinets, using standard set of hardware both powerful enough to run full logos stack and deterministic such that they can be configured with NixOS and near-guaranteed to run all dependencies without compatibility issues.

The increased cost of these devices (now basically little servers with terminals) would be justified if they can be guaranteed to support an arbitrary number of students, even though only one student a time can use the physical terminal. Hence the need for fully-deterministic student “state” that can be retrieved using keycard. Even while being actively used as a terminal, the server can host and expose services for anyone on the local network to use, e.g. RPC access, Codex storage, Relay for Waku light clients, etc. Could even stake/mine when no one is using it?

[marvin.jones]

There’s a brief mention of “lessons to learn” before stage 1. There’s some lessons mentioned: generate transaction, signing addresses, writing a script. Is there some key learning objectives that you have in mind?

[arseniy]

Great question, I guess ideally as students progress through the course they gain experience that increases their likelihood to make meaningful contributions to the same stack that they are installing on the devices. Since I’m not necessarily assuming the student’s level, it may be that just the experience of turning on a device without an operating system and installing a linux distro on it would be novel and interesting. It’s something I think we tend to forget when working in tech, that most people in the world have never even used a computer with Linux (idk if it’s true but I’m sure you get the gist) or ran a node or signed a transaction…

Hence the Lab in LogosLab, the kit is for general educational experiences with technology, it ultimately should depend on the setting where the lab is “set up,” whether or not there’s a facilitator who runs it, and the individual motivations of each student.

Both the hardware and software/instructional material in each kit should be modular, and custom tailored for different contexts. If a school or university isn’t allowed (or can’t get approval) for something involving cryptocurrency, then we can ship it just with Waku and say it’s for learning networking and distributed systems.

[vpavlin]

I generally like the idea of having reproducible learning environment - it helps to get around barriers like “does (not?) work on my machine”. At the same time, I think our focus here could/should be to let/encourage people to run Logos Core and Logo Stack components on their everyday devices - because if it is just for learning, then the custom hardware is not justified and if it is for using, then the hardware might be too limited.

Now I noted these 3 lines after our conversation on the way from dinner:

1. Build a retro-device with camera which would allow loging in by a wallet (using a QR flow amd signatures)
2. Place such devices at PSF campus with different task
3. Users login, perform a task and get a reward to their wallet (NFT, karma, Operator points…?)

I think for school/home learning doing it software + educational materials only makes most sense. Where the HW might come in are some “art installations” or “festivals” - like PSF, https://porcfest.com/, conferences, but also Logos Cells when/if those actually become a regular IRL thing:)

If I put it in a different way - by producing the kit with HW, you are also centralizing things:-) Why not just recommend people trusted HW vendors (like pine64) and let them buy their stuff - or not and just use their old-ish laptop sitting on the shelf? We can still provide them with exprience and the tools to get there (printed materials, branded flash drive with or without the system preinstalled, pointers to how to get to more). IMO that would be easier and also put less pressure on us to also ship HW around:)

Love the idea for coming up with some concise educational materials for the full stack nontheless!

[arseniy]

You’re right there are definitely trade-offs to consider with regards to whether or not we should include HW. I’ve asked Claude to review the thread and explore these trade-offs. I don’t necessarily agree with all of these, but still worth sharing:

Trade-offs of Including Hardware in Educational Kits

Based on the LogosLab concept discussed in the forum thread, here’s an analysis of the trade-offs between including dedicated hardware in educational kits versus software-only solutions.

Advantages of Including Hardware

1. Guaranteed Compatibility

   • Ensures that all software components will run properly on pre-tested hardware
   • Eliminates troubleshooting related to hardware incompatibility
   • Creates a consistent experience for all users

2. Complete Learning Experience

   • Provides an end-to-end experience from hardware to software
   • Enables physical computing concepts that software-only solutions cannot address
   • Allows for teaching hardware-specific skills (e.g., NFC, keycard usage)

3. Controlled Environment

   • Ensures security and privacy through purpose-built hardware (like the e-ink tablet with no wireless connectivity)
   • Prevents interference from other applications or services on general-purpose devices
   • Allows for deterministic behavior across all learning environments

4. Immersive Experience

   • Creates a dedicated space for learning without distractions
   • Physical hardware can create a stronger sense of ownership and investment
   • Branded hardware reinforces the identity of the learning experience

5. Accessibility

   • Removes barriers for learners without access to adequate hardware
   • Ensures equitable access to the learning experience regardless of personal resources
   • Eliminates the assumption that students already have compatible devices

Disadvantages of Including Hardware

1. Cost Barriers

   • Significantly increases the price point (potentially $600+ for the example kit)
   • May limit adoption due to budget constraints for individuals or institutions
   • Creates ongoing maintenance and replacement costs

2. Logistics Challenges

   • Requires manufacturing, inventory management, and shipping of physical goods
   • Creates support requirements for hardware issues
   • Necessitates considerations for repairs, replacements, and warranty services

3. Scalability Limitations

   • Physical hardware restricts how quickly and widely the solution can be deployed
   • International distribution introduces additional regulatory complexity
   • Hardware obsolescence can limit the lifespan of the educational product

4. Environmental Impact

   • Production and eventual disposal of hardware creates environmental concerns
   • Uses resources that could be avoided if existing hardware were leveraged
   • May contribute to e-waste when the hardware becomes outdated

5. Flexibility Constraints

   • Locks users into specific hardware capabilities and limitations
   • Makes it difficult to adapt to emerging technologies or requirements
   • Restricts usage to only the provided hardware rather than devices users already own and are comfortable with

6. Usage Continuity

   • May create “orphaned” hardware after the learning experience is complete
   • Presents challenges for ongoing use beyond the structured course
   • Could be underutilized if only needed for specific learning modules

Classroom-Specific Considerations

1. Shared Resource Management

   • The “arcade cabinet” approach allows multiple students to use the same hardware
   • Authentication systems (like keycards) enable personalization on shared hardware
   • Creates challenges around scheduling and access to limited physical resources

2. Maintenance and Administration

   • Educational institutions require dedicated IT support for hardware
   • Centralized management can be both an advantage (easier updates) and disadvantage (single point of failure)
   • Security and durability become significant concerns in shared environments

3. Usage Patterns

   • Hardware in classrooms typically has higher utilization rates than at home
   • Institutional purchases may justify higher initial costs through broader reach
   • The ability to serve many students over time improves the return on investment

Alternative Hybrid Approaches

1. BYOD with Verification

   • Allow users to bring their own devices but verify compatibility
   • Provide specific hardware components only when absolutely necessary (e.g., keycards)
   • Develop software with broad compatibility across common devices

2. Tiered Hardware Options

   • Offer both hardware-included and software-only versions
   • Create upgrade paths where users can add hardware components incrementally
   • Allow institutions to mix approaches based on available resources

3. Hardware Loan Programs

   • Implement borrowing systems rather than permanent ownership
   • Enable hardware sharing across multiple classrooms or students
   • Reduce per-student costs while maintaining the benefits of dedicated hardware

4. Virtual Hardware Simulation

   • Use virtualization to simulate hardware experiences
   • Enable learning hardware concepts without physical devices
   • Provide bridge solutions until physical hardware can be acquired

The ideal approach likely depends on specific educational goals, budget constraints, and target audience. For some applications, the controlled environment and guaranteed compatibility of included hardware may outweigh the cost disadvantages, while in other scenarios, focusing on software that works across existing devices may enable broader adoption and sustainability.

[arseniy]

What do you think about the “Classroom” section in my original post?

Something I want to encourage here is to ask not just “how do we think people should use our stack” but “what’s the best and easiest way to give our stack to people such that they can participate in learning experiences?”

I’m trying to make little to no assumptions about the student’s pre-existing knowledge. Most people in the world don’t know about pine64 or nixOS or even Linux… I actually experienced this first-hand at ETHIndia 2018 where I was a mentor. I found a team of young students, college freshmen basically, and they were trying to get truffle (smart contract dev environment) working on windows. Perhaps it was possible to get it working, but based on talking with them and gauging their level of experience (and honestly I had no desire to try and debug on a windows machine lol) I encouraged them to not stress out over trying to complete something for the hackathon and just spend the days trying to learn as much as possible, and familiarize themselves with linux, how it’s a good foundation to build for learning CS and becoming a developer, get it installed on their laptop etc. They were actually really really appreciative of me meeting them where they were at and told me I made the hackathon a much better experience for them!

I guess what I’m saying is we should “meet people where they’re at,” and for many it’s probably a level of technical knowledge much much lower than we assume. Packaging the experience of turning on a phone and there being no OS installed is already an opportunity for learning. It hints at something going on “under the hood” that most people don’t think about. Installing the OS is an even better opportunity for learning. It shows that what’s going on “under the hood” is actually accessible and can be modified by the user, not just the manufacturer. Running an OS that’s not standard Android/iOS? Another learning experience. So on and so forth…

There are definitely people out there who are more than capable of running the Logos stack on their own hardware, and would prefer to do so, but why not expand our potential reach to people who have yet to dip their toes into technology?

What if the LogosLab becomes someone’s very first experience of running open source software on open source hardware?

---

LogosLab within IFT

Let’s also “turn inwards” and explore how LogosLab can have an internal impact to IFT today and can perhaps help increase alignment.

There are about ~200 CCs. How many of those have experienced what I described above? How many have installed an open source operating system on open source hardware? How many have actually installed and run their own waku node, nimbus node, even if just a light client? The percentage may be lower than we think, and there’s no way it’s 100%. What would be the impact on the alignment of the organization if we brought that number up to 100%? If every single person in the org can relate to that shared experience?

[petty]

I won’t fully opine on this, but I have some general thoughts about it:

packaged hardware vs byoh

If you have a specific message to deliver, packaged hardware guarantees it’s easier to consume. If that is ever chosen as the route, it should be emphasized that it isn’t necessary, it’s just a convenience and an option. DappNode is a good example of such a thing. You can buy a dappnode, but you can also run it on anything of your own. Their tiers give a good indication of what resources are required to ensure feasible performance.

The IFT

We are arguably always the best testbed for ideas. We are the tribe. It needs to work with us before we can attract the right type of growth. That being said, we can’t limit ideas to come from only us. Anyone should be able to do whatever they want with our tech. How the IFT allocates resources to things is a signal of what we deem important to a larger tribe of people. We may be wrong in that allocation and it’s important that others can do it too.

first experience

I LOVE the idea of Logos being the first experience of someone building with linux.

Practicality

Identifying the first use case of what you do after building things up would be ideal. It needs to be something simple and light weight but also useful. A meshnet chat or something would be such an example. It allows for low resource devices and not too many modules and complexity to get started.

From there, upon demonstrated success in small spurts, can you identify how to grow and expand.

[arseniy]

@petty

I LOVE the idea of Logos being the first experience of someone building with linux.

Another way to frame it is Logos being the first experience of someone using a real computer.

[vpavlin]

Again, I feel like there are 2 parts in this - the HW and the SW.

We need to make it easy, reliable and reproducible to run the software - for production and educational purposes, regardless of the hardware - as long as we don’t depend on GPUs, specific TEEs or other specialized HW, most of our stack should run on commodity HW - including relatively old laptops, servers, miniPCs etc.

I am not convinced schools will be interested enough in the bundle/kit - I am regularly doing talks and elementary and high schools in CZ and their abilities, time and funds are limited.

I view HW and SW as separate and kinda ortogonal - like with Dappnode - you can run Dappnode software on Dappnode machine, or anywhere else, but you can also use Dappnode machine to run Dappnode software or anything else - it is just a re-packaged commodity HW.

If someone wants to build the kit with open HW, by all means, but I personally don’t see the effort extremely valuable to be pursued by the org - there have been attempts to create cheap open HW for “third world countries”, noble cause etc., but it never goes too far because it ends up being costly and limiting factor to the whole thing.

Scaling software and its distribution is way way easier than scaling HW:)

We can partner up with pine64 and come up with a bundled kit, sure, but I would much prefer to point people to existing solutions and materials for how to install a Linux operating system (unless/until we actually have one of our own:D) and then guide them in how to make it private, secure and using Logos stack.

Think about Logos core - we want it to run everywhere - any system, any machine. As soon as we start focusing on the lab kit, we might be tempted to neglect other environments.

Maybe we could find someone (some foundation, pine64 themselves, education org) that would actually maintain and manage this - find someone who is really good with Linux (mainstream distros maintainers, or some privacy focused one), we provide material for the Logos stack, someon (pine64?) provides devices and docs for that. And the someone packages and distributes that among their and our participants/contributors/community

I also agree that we should start from inside! Catia, for example, told me she wants to run Waku and Codex on her own laptop and that she needs to bring her laptop to a local shop to install Linux. I suggested she actually does that herself and that I am happy to assist. LFG! Let’s just do it with everyone, let’s prep a workshop “how to install linux”, let’s push it in Townhalls. IFT already provided us with HW, let’s use it for good:)

[arseniy]

There’s more I want to explore about the hardware kit and LogosLab in “classrooms” but I will more or less agree that it’s most likely not in the near-future.

It seems we’ve identified something that is much more pertinent in the near-term, that we can start soon, for which there are clear metrics, and can almost be thought of as the simplest PoC/dogfooding opportunity for the overall idea.

Can we reach 100% “experience coverage” of running and installing the Logos stack?

more thoughts soon