TootInstall
+ + + + + + + + + + + + + + + + + + + + +TootInstall Concept
+Status of this Memo
+This memo defines a conceptual protocol for software build and install scripts +for varying platforms published via Fediverse (ActivityPub i.e Mastodon, et al) posts.
+Overview
+These days, the options for software build and install processes are many,
+and jumping through the hoops required for some operating systems can be
+troublesome and sometimes impossible.
+Additionally, having to maintain many published packages for varying platforms
+is laborious, and sometimes means packages in some platforms become out of date
+and unmaintained.
+The TootInstall concept aims to bypass many of these requirements in an effort
+to have build and install scripts available for any application available on a
+decentralized, federated, all-accessible platform.
Usage - by Developers
+A software developer or package maintainer would post their script using their
+preferred federated ActivityPub service, and mention a tootinstall bot
+(i.e. @tootinstall_bot@tootinstall.example
). The tootinstall bot
would then
+parse the script and re-post it, giving attribution to the original poster.
It would be in everyone's best interests if all package requirements are listed +to ensure all dependencies are satisfied before attempting the install.
+For example, a simple tootinstall
script may look like the following:
@tootinstall_bot@tootinstall.example
++++
+name = "my_package"
+targets = ["linux+amd64", "linux+arm", "freebsd+amd64"]
+dependencies = ["bash","git"]
++++
+#!/usr/bin/env bash
+git clone https://gitrepo.example/me/my_package /tmp/my_package
+cd /tmp/my_package
+cp ./my_package /usr/local/bin/my_package
+
+which the bot would receive, and re-post like so:
++++
+name = "my_package"
+targets = ["linux+amd64", "linux+arm", "freebsd+amd64"]
+dependencies = ["bash","git"]
+author = "@you@a_mastodon_instance.example"
+date = "2024-29-07T14:48:00"
+status = "pending approval"
+tootinstall_host = "packages.tootinstall.example"
++++
+#!/usr/bin/env bash
+git clone https://gitrepo.example/me/my_package /tmp/my_package
+cd /tmp/my_package
+cp ./my_package.bash /usr/local/bin/my_package
+
+The tootinstall bot
should have RSS enabled for their posts, which is then
+parsed by a tootinstall helper
and collated into a tootinstall database
and
+published on a tootinstall host
.
Usage - by End Users
+An end user only requires a simple portable tootinstall
binary which can be
+used as follows:
tootinstall install my_package @packages.tootinstall.example
+
+TootInstall Bot
+A tootinstall bot
is a ActivityPub account that is able to read posts it is
+mentioned in, adapt incoming information and create new posts with correctly
+formatted tootinstall script
text.
It must:
+-
+
- be able to publish their ActivityPub feed via RSS so a
+
tootinstall helper
is able to easily read posts it sends for new +tootinstall scripts
.
+ - post a
tootinstall script
as a new post, +not a reply, nor a boost, nor a quote boost, nor anything similar, +to simplify RSS feed handling.
+ - create 'author', 'date', 'status', and
+'tootinstall_host' tags in the
tootinstall script
and ignore those in the +original post to prevent information poisoning.
+ - be able to operate a blacklist of accounts/instances to prevent spamming +
It may also be useful if it could:
+-
+
- receive boosts/favourites and forward these on to a
tootinstall helper
+for approval and scoring purposes (see Approvals and Scoring).
+
TootInstall Helper
+A tootinstall helper
is a background service that can read RSS feeds provided
+by configured tootinstall bots
collating all new tootinstall scripts
it
+has posted, store them in a database, and be able to search and return
+information about them as requested by a tootinstall
user binary.
It must:
+-
+
- be able to be configured to check multiple
tootinstall bot
RSS feeds to +allow for a more federated and decentralised service.
+ - be able to write to a persistent database +
- be able to return a script by name +
- NOT allow anyone other than the original author or maintainers to update a script +
- be able to operate a blacklist of accounts/instances to prevent spamming +
It would also be useful if it could:
+-
+
- increment a version number of a
tootinstall script
automatically. Incoming version numbers +should be ignored.
+
TootInstall Host
+A tootinstall host
is a web frontend used by tootinstall
user binary
+that is able to utilise the tootinstall helper
to return tootinstall scripts
.
It must:
+-
+
- be accessible on the internet +
- be able to search and return a list of packages in
json
format
+ - be able to return a specific package script by name in
toml
format
+
Endpoint URLs should be as follows:
+-
+
- /search?q=package_name +
- /install?p=package_name +
The TootInstall Bot, Helper and Host can all be the same system and do not necessarily need to be separate services
+TootInstall Script
+A tootinstall script
is a toml
document describing the dependencies and
+build/install process of a package.
+It has the following parameters:
-
+
- Editable: +
name : string : the package name (not editable after the first post)
+targets : array[string] : a list of os+arch targets
+dependencies : array[string] : a list of software dependencies required
+maintainers : array[string] : a list of ActivityPub accounts who can update a script
+
+-
+
- Non-Editable: +
author : string : the original author of the script
+date : datetime : the date and time the script was last updated (RFC3339)
+status : string : the status of the script (pending approval, approved, archived)
+tootinstall_host : string : the host on which this package has been published
+
+The Editable parameters are enclosed in +++
's to define separation between the
+parameters and the main script.
+A tootinstall script
should also include a shebang
to ensure the script runs
+as expected.
TootInstall Binary
+A tootinstall binary
is a simple portable binary that anyone can download and
+run to get TootInstall
functionality.
A guideline for usage is as below:
+tootinstall [mode] package_name @[tootinstall_host]
+ modes:
+ install - builds and installs the package as per the script
+ download - downloads a script but does not run it
+ search - searches the tootinstall url for a package name
+ inspect - finds and displays the tootinstall script
+
+ parameters:
+ package_name - Required. the package name to install or
+ search or inspect
+ @[tootinstall host] - Required. the host on which a tootinstall
+ database is running
+
+It must:
+-
+
- be able to access the internet +
- be able to search and download
tootinstall scripts
from multipletootinstall hosts
+ - be able to run the downloaded script +
- allow the user to inspect the script +
Verification
+The various tootinstall
bots and helpers should be configured to do some
+basic verification of the script poster.
Good examples of some basic checks are:
+-
+
- does the poster have a bio? +
- does the poster have an image? +
- has the poster been active on the fediverse for a reasonable amount of time +
- has the poster been interacting with people of the fediverse for a reasonable +amount of time? +
- does the poster have some other people following them? +
- has the poster ever been boosted and/or favourited by somebody else a few times? +
Scoring
+As a popularity/rating service, we can utilise ActivityPub boosts and favourites
+as a scoring platform for tootinstall scripts
.
-
+
favourite
= "I like this" = 1 point
+boost
= "I want other people to see this" = 1 points
+
A favourite and a boost from one account can give a script 2 points.
+Approvals
+It would not be sensible to publish a script immediately after posting as
+doing so massively increases the risk of distributing malware.
+Instead, it would be wise to implement an approval concept whereby authorised
+accounts could authorise a script by replying to the tootinstall bot
's post
+with an approval state i.e. "approved" or "denied". A tootinstall bot
could
+also actively seek out approval from a list of configured accounts, and post the
+script privately to them before actually posting the published script.
+Secondary to this, we could implement a form of crowdsourced approval whereby if
+a script score reaches a certain level, it is automatically approved.
Written by Paul Wilde - 29th July 2024
+@paul@notnull.space
+Final Notes
+OK… let's address the elephant in the room. I am very aware this is incredibly +dangerous and you should be very aware this is a parody concept. +Please, everyone, PLEASE, do not implement any of this!! It is just meant as a +humorous thought experiment and is in no way intended to make it to production.
+ ++