Role-Based Access Control (RBAC)

Mike's Notes

I'm revisiting the role-based access control (RBAC) in Pipi.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

13/09/2025

Role-Based Access Control (RBAC)

By: Mike Peters
On a Sandy Beach: 08/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4

Pipi utilised a simple role-based access control (RBAC) system. It enforced a change of passwords for both admins and users. The old data model was similar to the one depicted in this diagram.

Pipi 9

Using RBAC to administer accounts for users must scale from very simple to large. Something much more robust is required.

Requirements

Entities;

  • Users
  • Policy
  • Roles
  • Permissions
  • Groups
  • Objects
  • Sessions
  • Join tables

Roles;

  • In a hierarchy.
  • Separation of duties by allowing and denying access.
  • Fine-grained.

Uses;

  • Pipi as an ecosystem and an individual system.
  • Each account
  • Organisational structures within an account
  • Shares
  • Individual users
  • The public
The RBAC needs to be automatically logged, tested and audited.

Fuzz Testing

Mike's Notes

Automated self-testing is needed for Pipi. Something like Chaos Monkey would be great. These are working notes as I learn and do some experiments.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

07/09/2025

Fuzz Testing

By: Mike Peters
On a Sandy Beach: 07/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi is a self-organising system that can autonomously adapt. This makes it difficult to integrate external standard software tools. However, it requires robust testing to make it tough and reliable. One way might be to deliberately provide a hostile environment for Pipi.

Ecosystem Testing

A copy of Pipi could attack other copies as a way to automate testing. Both the hunter and the hunted could have an arms race, forcing evolutionary-driven survival. This might work well with the internal evolutionary algorithms.

Survivors would go into production.

Random Testing

"Random testing is a black-box software testing technique where programs are tested by generating random, independent inputs. Results of the output are compared against software specifications to verify that the test output is pass or fail. In case of absence of specifications the exceptions of the language are used which means if an exception arises during test execution then it means there is a fault in the program, it is also used as a way to avoid biased testing." - Wikipedia

Monkey Testing

"In software testing, monkey testing is a technique where the user tests the application or system by providing random inputs and checking the behaviour, or seeing whether the application or system will crash. Monkey testing is usually implemented as random, automated unit tests." - Wikipedia

Fuzz Testing

"In programming and software development, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks. Typically, fuzzers are used to test programs that take structured inputs. This structure is specified, such as in a file format or protocol and distinguishes valid from invalid input. An effective fuzzer generates semi-valid inputs that are "valid enough" in that they are not directly rejected by the parser, but do create unexpected behaviors deeper in the program and are "invalid enough" to expose corner cases that have not been properly dealt with.

For the purpose of security, input that crosses a trust boundary is often the most useful. For example, it is more important to fuzz code that handles a file uploaded by any user than it is to fuzz the code that parses a configuration file that is accessible only to a privileged user." - Wikipedia

J.D.Ullman

Mike's Notes

References to the life's work by Stanford Professor J.D.Ulman on databases. He wrote excellent books and articles on other subjects as well. These are classic works. Includes a lot of free downloads.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Authors > J.D.Ullman
  • Home > Handbook > 

Last Updated

06/09/2025

J.D.Ullman

By: Mike Peters
On a Sandy Beach: 06/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

"Jeffrey David Ullman (born November 22, 1942) is an American computer scientist and the Stanford W. Ascherman Professor of Engineering, Emeritus, at Stanford University. His textbooks on compilers (various editions are popularly known as the dragon book), theory of computation (also known as the Cinderella book), data structures, and databases are regarded as standards in their fields. He and his long-time collaborator Alfred Aho are the recipients of the 2020 Turing Award, generally recognized as the highest distinction in computer science." - Wikipedia

Windows LTSC

Mike's Notes

A stable platform is required for the isolated Ajabbi Research Data Centre, which is not connected to the internet. The platform O/S needs to be stable and not require weekly updates for Pipi to run on. Ideally, the platform and the major Pipi version would be updated simultaneously every 2-5 years.

The basic ISO build required is

  • O/S (Windows or Debian Linux)
  • Jave 21 JRE
  • BoxLang

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

24/11/2025

Windows LTSC

By: Mike Peters
On a Sandy Beach: 05/07/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I like using Windows. It's because I'm very visual and need a GUI.

I have no problem with Linux, but that would require others who can spell and are familiar with the command line.

Pipi can use the command line autonomously because every command is carefully loaded into a database, ready for use in a CFML template.

The biggest challenge with using Windows O/S in the isolated data centre is dealing with O/S updates. It turns out that Microsoft offers a version of Windows specifically designed for embedded applications, such as those found in hospitals and factories. Perhaps that would be a better option for creating initial platform stability. I need to do some experiments.

Later, as Ajabbi grows and more people are involved, switching to a minimal version of Debian Linux could be easily done. Maybe as part of the next major version, Pipi 10.

LTSC

  • It seems to be slimmed down.
  • Doesn't have CoPilot, OneDrive, the Microsoft Store and Cortana.
  • Can run Java
  • Windows 10 LTSC is supported until 2033.
Next steps
  • Try it out

Progress on the rack

Mike's Notes

Some notes on building out the first server rack cabinet.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

13/09/2025

Progress on the rack

By: Mike Peters
On a Sandy Beach: 04/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Building out the first server 45U rack cabinet to host Pipi 9 has been a slow process. Mainly because I was working on other things. Pipi 9 works a bit like a render farm, so it will not be connected to the internet for security reasons and will batch-create products that can be shared via GitHub.

Reusing

There is a significant amount of old rack gear from Pipi 4 in storage that is still usable, which I need to locate and either put to use or dispose of.

  • KVM switch.
  • Power distribution board.
  • Shelving.
  • Air cooling.
  • Cabling.
  • Network Switches.
  • Monitor.
  • 4 old Win servers.

Buying new

I was able to obtain some more gear this week.

  • 16GB RAM 64-bit Windows Server.
  • Rack Cabinet LCD Monitor Mount Bracket.

The small 16GB RAM server consumes low power, allowing it to run continuously and regulate the entire system. There are enough older servers that can be reused and switched on/off for batch jobs. They will do till they get replaced by better gear.

Need

What I don't have is

  • Smart UPS.
  • Rack keyboard.

The next job

  • Making a standard Java 21 + BoxLang install bundle to put on all machines and run Pipi 9 CFML.
  • Learn as I go.

Localisation options

Mike's Notes

I had to make some hard decisions on localisation as used by Pipi. The localisation system was built in 2023, populated, tested and then never used.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

29/09/2025

Localisation options

By: Mike Peters
On a Sandy Beach: 03/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The Localisation Engine (loc) stores the configuration required to create a website in a language that uses a writing script and may vary by region. It utilises standard codes, such as Unicode, which can be imported and easily kept up to date. The Engine provides a read-only configuration file system-wide.

The Engine can also provide strings in any language and writing script for placing in the User Interface. Words like 

  • Home
  • Password
  • Username
  • Login
  • Save
Each copy of Pipi comes in one language, allowing different copies to be automatically built in various languages.

i18n

Languages

  • A 3-letter string is added. e.g. eng for English and mri for Maori.

Writing scripts (alphabets)

  • A 4-letter string is added for the script. e.g. latn for Latin.

Locales

  • A 2-letter capitalised string is added. e.g. eng-latn-GB for English spoken in the UK, eng-latn-US for English spoken in the United States.

The internal control hierarchy of Pipi

Mike's Notes

I'm writing up some notes on current work driven by a teaching customer.

i18n

  • For Languages, a 3-letter string is added. e.g. eng for English and mri for Maori.
  • For Writing Scripts (alphabets), a 4-letter string is added for the script. e.g. latn for Latin.
  • For Locales, a 2-letter capitalised string is added. e.g. eng-GB for English spoken in the UK, eng-US for English spoken in the United States.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/04/2026

The internal control hierarchy of Pipi

By: Mike Peters
On a Sandy Beach: 02/09/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi is a self-organising system. Self-regulating constraints are operating on internal models. There are numerous internal hierarchies of control within Pipi, with properties that are inherited, including multi-inheritance.

Examples include;

  • Class packages: eg, namespace
  • Nested systems: eg, Account > Deployment > Deployment Object > Publication > Website > Workspace
  • Schema, ontologies, etc: eg, SNOMED, MovieLab
  • Design systems: eg, Account > Design System > Component > Design Token

Descriptions

Pipi Nest

Each account can only be in a single nest

  •  <pipi major version><pipi edition><account type>

Account

Every customer or user has an account, which is opened when they sign up.

A customer account has these properties;

  • One account type.
  • Contains one or more deployments.

Account types:

Each account type comes with different options. Enterprise has the most options, and Individual has the least.

  • DevOps (paid).
  • Enterprise (paid).
  • Individual (free).
  • Pipi (paid)
  • Researcher (paid)
  • SME (paid).
  • Temp (free)

Deployment

A deployment has these properties;

  • One deployment tenancy type.
  • One language.
  • Contains one or more deployment objects.
  • Can contain other deployments to create global settings for an account (Enterprise or DevOps).

Deployment tenancy types:

  • Exclusive tenancy
  • Shared tenancy
  • Multi-agent

Deployment Object

A deployment object has these properties;

  • One deployment object type

Deployment Object Types:

Used by the administrator through configuration settings.

  • Billing
  • Datasource
  • Folders
  • Permission
  • Plugin
  • Publication
  • Usage
  • Users and Groups
  • etc

    Publication

    All publications are created by the Content Management System (CMS).

    A publication has these properties;

    • One publication type.
    • It can be combined to build a whole system.
    Publication Types
    • Code
    • CSS
    • Database
    • Deployment
    • Email Newsletter
    • Notebook (Jupyter, etc)
    • PDF
    • Website
    • XML
    • etc

    Website

    A website has these properties;

    • One language. 
    • One website type.
    • Can be combined with other websites (to become a multi-language website).
    Website types
    • API (Endpoints)
    • Docs (like JavaDocs)
    • Help
    • Website (standard)
    • Wiki
    • Workspace (enterprise applications)
    • etc

    Example

    ASCI internal names are automatically provided by Pipi. A customer can choose different public names for URLs.

    An example control hierarchy;

    Pipi Nest > Account > Deployment > Deployment Object > Publication > Website > Workspace.

    Inheritance Internal name Examples
    Pipi Nest Pipin Nest:
    <pipi major version><pipi edition><account type>
    9ae
    Account <ASCI characters> ajabbi
    Deployment <Account>-<4 Digit>-<Locale> ajabbi-0001-eng-latn-uk
    Deployment Object <Deployment>-<ObjectType> ajabbi-0001-eng-latn-uk-pub
    Publication <Deployment Object>-<Publication Type> ajabbi-0001-eng-latn-uk-pub-cde
    ajabbi-0001-eng-latn-uk-pub-dta
    ajabbi-0001-eng-latn-uk-pub-wbs
    Website <Domain> wiki.example.com/eng-latn/
    blog.example.com/en-nz/
    en.example.com/uk/
    workspace.example.com/eng/

    GitHub Nuked My Account at Midnight During Alpha Release: Why I Rage-Quit to GitLab

    Mike's Notes

    GitHub is not 100% reliable, as this personal account shows.

    Main lesson learned

    "...always maintain local backups and use multiple platforms"

    Resources

    References

    • Reference

    Repository

    • Home > Ajabbi Research > Library >
    • Home > Handbook > 

    Last Updated

    01/09/2025

    GitHub Nuked My Account at Midnight During Alpha Release: Why I Rage-Quit to GitLab

    By: Christopher Kvamme
    Stack Junkie: 04/08/2025

    Christopher Kvamme is a well-rounded hardware engineer and software developer with a passion for exploring cutting-edge technologies and AI integration. He documents his experiments, learnings, and real-world development challenges through Stack Junkie.

    When he's not building web applications or experimenting with the latest frameworks, Christopher enjoys sharing transparent insights about the development process, including both successes and failures. His goal is to demystify modern web development and AI implementation through honest, practical content.

    Stack Junkie serves as both a learning journal and a resource for developers navigating the rapidly evolving landscape of web technologies and artificial intelligence.

    Quick Summary

    GitHub straight-up deleted my account containing loads of work during the most critical moment possible—midnight alpha release. Zero warning. Zero explanation. Zero f*cks given about their users.

    Introduction

    You know that feeling when you're about to hit a major milestone and the universe decides to take a massive dump on you? That was me five days ago.

    Picture this: It's midnight. I've been grinding for HOURS on my app's alpha build. The code is beautiful. Tests are green across the board. This is it—the moment I've been working toward for months. I hit that satisfying git push, ready to pop open a celebratory Red Bull.

    Then Capacitor's Appflow starts throwing errors. "Repository doesn't exist."

    Little did I know, I was about to experience the digital equivalent of coming home to find your house bulldozed with all your stuff inside. And the demolition crew? Gone. No note. No "sorry we destroyed your life." Nothing.

    The Night GitHub Betrayed Me (And Every Developer Who Trusts Them)

    The Moment Everything Went to Hell

    Let me paint you the full picture of this disaster. After pushing what should have been my glorious alpha build, I switched over to my deployment pipeline. That's when things got... interesting.

    Capacitor's Appflow Ionic was having a meltdown:

    "ERROR: Repository not found"

    "ERROR: Authentication failed"

    "ERROR: [Insert more soul-crushing errors here]"

    My first thought? Must be a glitch. GitHub's probably having issues. , Oh, I just need to login again, I'm sure it's fine , I just pushed some features half an hour ago, nothing could have changed

    I received an error saying the Github repo didn't exist. I followed the link to my own repo. And there it was-

    The Five Stages of Developer Grief

    Stage 1: Denial

    • "This can't be right. Let me just refresh..."
    • Refreshes seventeen times
    • Clears cache
    • Tries different browser
    • Turns PC off and on again per every IT person ever

    Stage 2: Confusion

    I navigate to GitHub. I'm logged out. Odd as I was just logged in.... So I try to log in?

    • No error message
    • No "incorrect password"
    • No "account suspended"
    • Just... nothing. Like my account never existed.

    Stage 3: Panic

    This is when it hits. My repositories. My projects. My commit history. My entire existence on GitHub—GONE.

    I frantically check:

    • Email? Nothing.
    • Spam folder? Nada.
    • Junk? Zip.
    • The "Promotions" tab? Empty.

    It's gone!

    Stage 4: Rage

    The realization that I can't even submit a support ticket because YOU NEED AN ACCOUNT TO SUBMIT A TICKET. The irony wasn't lost on me. It was like being locked out of your house and being told you need to call for help from inside the house.

    Stage 5: Whatever This Feeling Is

    This seems to be just a matured version of stage 4. Just more a more creative version of rage. I imagine their system is like this for a reason. But if the reasons for this are boiled down to one exchange, I'll bet it was something like the classic: Github Boss 1: "Sir, we have too many support tickets. We need to get those issue numbers down to meet our KPIs." Github Boss 2: "Well, just ban people who might want to submit a ticket. Then the ticket count will go down." Github Boss 1: "Of course!" Both: Evil laugh

    The Support Ticket Saga

    I come up with a plan to get answers. I dig up my ancient personal GitHub account (thank god for old burner accounts) just to submit a support ticket. You'd think they'd prioritize "YOUR PLATFORM DELETED ALL MY WORK" tickets, right?

    • Day 1: Submit ticket. Automated response says they'll get back to me "soon."
    • Day 2: Nothing.
    • Day 3: Still nothing.
    • Day 4: Cricket sounds
    • Day 5: I start writing this blog post because clearly GitHub has better things to do.

    The Timing Couldn't Be More Perfectly Awful

    It was nearly midnight when I hit “git push” for my alpha build—just in time to see Capacitor Appflow spit back an error claiming the repo didn’t exist. That’s when I discovered:

    My GitHub account was logged out with zero warning or message.

    Every single repository (including my main app and all backups) had vanished.

    Appflow builds broke instantly because there was nothing to pull.

    Hours of coding and my sanity were wasted in the blink of an eye.

    GitHub’s cold, automated ban didn’t care about my release schedule, my midnight deadline, or the projects I thought were safely stored. Zero humanity. Zero consideration. Just cold, automated destruction.

    The Great Migration: Finding Refuge in GitLab

    After spending about 47 minutes alternating between denial and rage, I knew it was time to press forward. To pick up the pieces. The show must go on, even if GitHub decided to yeet me into oblivion. In fact, I was better off that they did this. Better I learn this lesson now instead of later when I had more to lose.

    I began my hunt for a new home for my projects. I chose GitLab.

    Why GitLab? Let me count the ways:

    • They actually communicate - wow, right?
    • Self-hosting options - Because fool me once...
    • Better CI/CD - Get rekt, Github.
    • Transparent operations - !!!

    The Migration Process

    Step 1: Create Your Escape Route

    # If you still have local copies

    git remote rename origin github-old

    git remote add origin https://gitlab.com/yourusername/yourrepo.git

    Step 2: Push Everything

    # Push all branches because who knows what you'll need

    git push -u origin --all

    git push -u origin --tags

    Step 3: Update Your Life

    CI/CD pipelines → Point to GitLab

    README badges → Update those URLs

    Team access → Re-invite everyone

    Webhooks → Reconfigure them all

    The rest → Update the link everywhere

    Your soul → Begin healing process

    Building My Paranoid Backup Strategy

    This event caused me to lose a certain amount of trust when it comes to these platforms. And in hindsight, in my profession I should know already, to have redundancies in place. The only logical next step is making sure no one can do that ever again.

    • Primary: GitLab (with all the features)
    • Secondary: Self-hosted Gitea instance (because trust issues)
    • Tertiary: Local server running automated pulls
    • Quaternary: Encrypted backups to cloud storage
    • Paranoid Level: USB drives in a fireproof safe

    Which is a good start....

    During the Writing of this Article

    I attempted to login to Github to obtain a screenshot of the lack of error from login attempts. And was finally greeted with a message stating my account was suspended. They provided me the ability to submit a ticket with my banned account. How considerate of them...

    My Message to GitHub (If They Ever Read This)

    Github ticket submission

    Dear GitHub,

    You people turned off my account with no notice or cause whatsoever. There wass no explanation. I was in the middle of trying to push the alpha for my app after spending countless hyours working on it. I didnt receiver any message why. and no errors when trying to log in.

    It's now been five days. And finally it says my account was suspended when I try to login. And now you are making me come to you... hat in hand... to appeal for access back to MY WORK!? My work, that was nuked for no reason whatsoever. I don't have much of a platform, but I may have one someday. And I promise you, random Github support person, that I'm making it my life's mission to hurt Github like Github hurt me.

    Every opportunity I get, I'll steer people away from this platform. I'm going to promote every single alternate platform while damaging Github. And I'll do it just by telling the exact truth about what happened.

    I will not rest until "Github treats their users like insignificant pieces of dirt. They don't extend the common courtesy to explain when people's hard work gets disappeared. Actions which are rooted from their apathetic view towards the people who love their services" is at the top of every internet query with 'Github' as one of the search terms.

    I may be one person, and you may be a multi-million dollar corporation (probably), but I assure you I'm not alone. Because you have treated many people like this. We will find each other, raise awareness. And then, you will know our names. But also then.... it'll be too late. You'll be finished

    Consider this my villain origin story.

    Next Steps

    There are additional steps that needed to be done to make me immune to future mass deletion events. And this is all anyone really can do.

    1. Finish migrating everything to GitLab (90% done)
    2. Set up automated backups (because paranoia is justified)
    3. Document everything for the next person GitHub screws
    4. Share this story everywhere (starting now)
    5. Build something awesome on a platform that respects developers

    If I were to give Github their due, they could very well have had a good reason to disappear my account. Maybe they didn't like that I was making lots of commits after my experience with my last mass deletion event. Perhaps they are just understaffed and have a huge backlog of support tickets they're working on. And most of all, perhaps this happening to me or anybody else isn't personal. And could just be a one-off event, or accident.

    WRONG

    Github has been deleting peoples work without explanation for years. Often times those people had a lot more to lose than me. Here is a situation where someone was more inconvenienced than I:

    [Ed] See the References for Author Nikolay's experience

    I wanted to bring examples of this happening to people. It wasn't hard. Googling "Github deleted my account no notice." You will be greeted with page after page of testaments. This is happening frequently, and has been a problem for years! One Ban, Two Ban, Three Ban, Four, Five Ban, Six Ban, Seven.

    My initial gut reaction after plowing through the stages of grief is usually to consider the other side. But when there are instances of this happening that I found from 2020 and earlier, they have had time to fix it. As easily as their automated systems delete accounts and cause all this hurt. A note informing the user what they did wrong could go a long way. It wouldn't help the pain, but it would save users from suffering the "not knowing" aspect of it all.

    Github is a private company, of course. They are free to run things however they'd like. But we as developers don't have to put up with that. Don't use Github.

    Tell me about your experience at the X link below. Has this happened to you? What did you do in response? I want to hear all about it.

    FAQ

    • Why did GitHub delete accounts without warning?
    • GitHub uses automated systems that can delete accounts without human review, providing no explanation or recovery options.


    • How do I migrate from GitHub to GitLab quickly?
    • Use GitLab's import tool or update your git remotes: rename origin to github-old, add GitLab as new origin, push all branches and tags—takes under 10 minutes if you have local copies.


    • Can you recover deleted GitHub repositories?
    • No. Once GitHub deletes your account, everything is gone permanently with no recovery options—always maintain local backups and use multiple platforms.


    • What's the best GitHub alternative in 2025?
    • GitLab offers superior transparency, self-hosting options, and integrated CI/CD, plus they actually respond to support tickets—something GitHub apparently forgot how to do.


    • How do I backup Git repositories automatically?
    • Set up a cron job to pull all repos nightly, use tools like gitbackup, mirror to multiple platforms, and keep encrypted archives in cloud storage. Paranoia is your friend.

    FFmpeg 8.0 "Huffman"

    Mike's Notes

    FFmpeg has been updated. Used by Pipi. Automation via the Command Line.

    Resources

    References

    • Reference

    Repository

    • Home > Ajabbi Research > Library >
    • Home > Handbook > 

    Last Updated

    26/08/2025

    FFmpeg 8.0 "Huffman"

    By: FFmpeg
    FFmpeg: 22/08/2025

    A complete, cross-platform solution to record, convert and stream audio and video.

    FFmpeg is the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created. It supports the most obscure ancient formats up to the cutting edge. No matter if they were designed by some standards committee, the community or a corporation. It is also highly portable: FFmpeg compiles, runs, and passes our testing infrastructure FATE across Linux, Mac OS X, Microsoft Windows, the BSDs, Solaris, etc. under a wide variety of build environments, machine architectures, and configurations.

    It contains libavcodec, libavutil, libavformat, libavfilter, libavdevice, libswscale and libswresample which can be used by applications. As well as ffmpeg, ffplay and ffprobe which can be used by end users for transcoding and playing.

    The FFmpeg project tries to provide the best technically possible solution for developers of applications and end users alike. To achieve this we combine the best free software options available. We slightly favor our own code to keep the dependencies on other libs low and to maximize code sharing between parts of FFmpeg. Wherever the question of "best" cannot be answered we support both options so the end user can choose.

    +++++++++++++

    A new major release, FFmpeg 8.0 "Huffman", is now available for download. Thanks to several delays, and modernization of our entire infrastructure, this release ended up being one of our largest releases to date. In short, its new features are:

    • Native decoders: APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728
    • VVC decoder improvements: IBC, ACT, Palette Mode
    • Vulkan compute-based codecs: FFv1 (encode and decode), ProRes RAW (decode only)
    • Hardware accelerated decoding: Vulkan VP9, VAAPI VVC, OpenHarmony H264/5
    • Hardware accelerated encoding: Vulkan AV1, OpenHarmony H264/5
    • Formats: MCC, G.728, Whip, APV
    • Filters: colordetect, pad_cuda, scale_d3d11, Whisper, and others

    A new class of decoders and encoders based on pure Vulkan compute implementation have been added. Vulkan is a cross-platform, open standard set of APIs that allows programs to use GPU hardware in various ways, from drawing on screen, to doing calculations, to decoding video via custom hardware accelerators. Rather than using a custom hardware accelerator present, these codecs are based on compute shaders, and work on any implementation of Vulkan 1.3.

    Decoders use the same hwaccel API and commands, so users do not need to do anything special to enable them, as enabling Vulkan decoding is sufficient to use them.

    Encoders, like our hardware accelerated encoders, require specifying a new encoder (ffv1_vulkan). Currently, the only codecs supported are: FFv1 (encoding and decoding) and ProRes RAW (decode only). ProRes (encode+decode) and VC-2 (encode+decode) implementations are complete and currently in review, to be merged soon and available with the next minor release.

    Only codecs specifically designed for parallelized decoding can be implemented in such a way, with more mainstream codecs not being planned for support.

    Depending on the hardware, these new codecs can provide very significant speedups, and open up possibilities to work with them for situations like non-linear video editors and lossless screen recording/streaming, so we are excited to learn what our downstream users can make with them.

    The project has recently started to modernize its infrastructure. Our mailing list servers have been fully upgraded, and we have recently started to accept contributions via a new forge, available on code.ffmpeg.org, running a Forgejo instance.

    As usual, we recommend that users, distributors, and system integrators to upgrade unless they use current git master.

    Enterprise plan directory structure

    Mike's Notes

    Pipi 9 is still highly experimental. I have been very busy over the last month working on the second deployment of Pipi 9 to production.

    • The first (dogfooding) is Ajabbi.com.
    • The second (pilot) is for a national disability rights organisation in NZ.

    The second has been very slow, mainly because it involved the migration of an existing website to a new one, which required careful consideration of the organisation's needs, including using 4 languages (English, Maori, NZ Sign Language, AAC), catering for screens-formats (mobile, desktop, braille, screenreaders, kiosk, TV), and personalised profiles to meet accessibility needs. There have been six months of extensive experimentation and user testing using a manually created 1,100-page static website prototype. Last week, the successful import of existing content into a CMS database was completed. The job now is to connect Pipi 9 to this database to automate future production of all website content.

    These notes are about the draft default directory structure for that website. All other 26 existing websites have now been migrated to use the same default structure.

    Update 30/03/2026

    Putting the data centre into production has resulted in some changes.

    Data directory for databases external to Pipi
    1. data/
    2. <Database Type>/ eg "pg"
    3. <Database Version No>/ eg "18"

    Pipi directory

    1. pipi/
    2. <Account type>/ eg "e"
    3. <Account Name>/ eg "ajabbi"
    Work directory for backups, etc
    1. work/

    Update 04/04/2026

    Pipi Robot added to description.

    Update 06/04/2026

    <major version><edition><account type>/ added to all configurations to standardise and simplify setups.

    Update 11/04/2026

    Pipi Nest is used as the name for the root config.

    Update 15/04/2026

    <account name(s)> AND <instance name(s)> both present.

    Resources

    References

    • Reference

    Repository

    • Home > Ajabbi Research > Library >
    • Home > Handbook > 

    Last Updated

    23/04/2026

    Enterprise plan directory structure

    By: Mike Peters
    On a Sandy Beach: 18/08/2025

    Mike is the inventor and architect of Pipi and the founder of Ajabbi.

    This is the current default directory configuration for enterprise plan customer accounts. It should also work for the digital twins in the Pipi 9 data centre.

    The account administrator can edit the configuration file to easily change the location of these key directories for a particular cloud host.

    • AWS
    • Azure
    • GCP
    • IBM
    • Oracle
    • etc. 

    On a public-facing website, all of this would be obfuscated using UUIDs, hidden keys, etc.

    Pipi Robot

    The hidden robot contains most of the complex systems and functions and acts as the super-administrator, thereby simplifying enterprise applications.

    Configuration File

    /9ae/ (Pipi Nest)

    • pipi_nest_probe.cfm
    • data/
      • couchbase/
      • db2/
      • derby/
      • h2/
      • hsqldb/
      • informix/
      • mariadb/
      • msaccess/
        • 32/
        • 64/
      • mssql/
      • mysql/
      • oracle/
      • pg/
        • 18/
      • sqllite/
      • sybase/
      • virtuoso/
    • pipi/
      • Application.cfc (1) - Nest settings
      • pipi_nest.cfm
      • ajabbi/ (Account Name)
        • Application.cfc (2) - Account settings
        • pipi_account.cfm
        • com/
        • dat/
        • lib/
        • log/
        • plu/
        • tmp/
        • www/
          • learn.ajabbi.com/
            • Application.cfc (4) - Website settings
          • wiki.ajabbi.com/
            • Application.cfc (4) - Website settings
      • dis-01/ (Instance)
      • ...
      • dis-04/ (Instance)
        • Application.cfc (2) - Account settings
        • pipi_account.cfm
        • pip/
          • Application.cfc (3) - Version settings
          • pipi_version.,cfm
          • i18n/
          • log/
          • pipi_<pipi version>.txt
          • sys/
          • temp/
          • template/
            • _include/
            • _layout/
              • _log/
        • www/
          • mission-control/
            • Application.cfc (4) - Website settings
    • work/
      • backup/
      • install/
      • project/

      Descriptions


      Directory Example Description
      <major version><edition><account type> 9ae/ Pipi Nest:
      Major version = 9
      Edition = a (Pipi Application)
      Account type = e (Enterprise).
      <account name> ajabbi/ User account codename (lowercase, unique ASCII).
      com com/ Open-source code packages from GitHub.
      dat dat/ Customer data.
      lib lib/ Code libraries.
      log log/ Logs.
      plu plu/ Open-source plugins.
      tmp tmp/ Temporary files.
      www www/ All websites.
      <website> wiki.ajabbi.com/ A website (domain name).
      <instance name> dis-01/ Pipi instance name (retired deity, lowercase, unique ASCII).