Pinned toot

YAAPS and Sputnik Opphuichi are complementary approaches to getting a working ActivityPub server in Lua. Sometimes features require related infrastructure to develop; Occasionally, a clean start is better

That being the case, I need to exercise a little self care and stop being critical with myself for switching emphasis between the two projects

In order to make it easier for people to be helpful, I'm breaking both projects into smaller chunks. This means that Sputnik Neptune is going to be the last release on a permissive license. Opphuichi will be AGPL

As a prelude to updating the repos, I'm going to attempt a thread here where I describe each component

Pinned toot

This is the official account for , an early stage fediverse project to resist late stage capitalism. It's pure ActivityPub, 100% Lua, and guaranteed vaporware if I spend as much time here as my main

Hi, we just released a new version of ValueFlows (v.3) at https://valueflo.ws/.

"Value Flows is a set of common vocabularies to describe flows of economic resources of all kinds within distributed economic ecosystems."

"Purpose: to enable internetworking among many different software projects for resource planning and accounting within fractal networks of people and groups. The vocabulary will work for any kind of economic activity, but the focus is to facilitate groups experimenting with solidarity / cooperative / collaborative / small business ecosystem / commons based peer production / any transitional economies."

@bhaugen @bhaugen @yaaps @mayel @ivan

A VR headset is just headphones for your eyes

@yaaps that extra hop is fundamentally the problem, but people are responding in the wrong way, because they are riled up by people who capitalize on riling people up.
the efforts people are putting into bullying others into blocking or not blocking XYZ instance should instead be put into lobbying for OCAP to be adopted across the fediverse. OCAP narrows the trust assertion to something far more reasonable. over time, the trust assertion can be narrowed further.

there will always be a trust assertion, but OCAP makes these assertions *manageable*
right now, in ActivityPub (and in OStatus before it), the trust model is:

do you trust this peer and their peers?

OCAP (and also authenticated fetches) changes the trust model to:

do you trust this peer?

but there is still a trust assertion. OCAP and similar solutions do not solve bad actors entirely.

there will *always* be a trust assertion.

trust is the only thing that makes the fediverse work.

Say what you will about the drama, but Glimpse is a really good name for an image manipulation program. Yes the reasoning for the name change is sound but OMG WHAT A GOOD NEW NAME

Apart from storage and parsing, and routing to the Boot Service, YAAPS will be considered feature complete when the API for interacting with the Boot Service is written and documented

The implication is that functionality will be defined and configured by posting to an Outbox with the necessary capabilities

The API for interacting with that Outbox will cover creating and delegating capabilities for object persistence, http routes, and replication to remotes, and placement of privileged protocol segments to initialize access to an existing service. The existing service can be any routable location as defined by the protocol in the privileged section and will not need to exist on the same machine

The bootstrap consists of a Service Actor with the capability of Creating other Actors. It responds programmatically to messages on its Inbox according to a policy

On a fresh install, this service will be configured to Create an ephemeral Actor with limited capabilities for anonymous use, utilize Offer/Accept semantics on its Inbox to Create unprivileged Actors, to Follow an Actor Created if its Follow Collection is empty, and to administer capability grants for Actors in its Follow Collection

So, the network layer...

The flow for a new Object received on the wire begins with the object to which it is posted. That target will be a Collection - either an Inbox or an Outbox. The Owner of the Collection, which may be a Service Actor, determines the capabilities available when processing the Object

The received object becomes the properties of an object whose methods are inherited from a prototype that the owner of the Collection previously delegated to that authorization

Since an ActivityPub conformant Federated Server isn't necessarily an ActivityPub conformant Client, there will be Inboxes designed as relays so that the object of a Create Object federated to the Inbox, once Authority is confirmed, may be placed in the Outbox of a local client as if it had been POSTed directly

With that exception, Objects on the Inbox are committed to temporary storage and Outbox Objects are committed to persistent storage, then added to relevant Collections, and finally those recipients that the service is responsible for notifying are notified

Multilingual pun (These never work well. This one isn't any exception) 

I started with a Discworld metaphor for YAAPS where Sputnik is the counterweight continent and it's ActivityPub (elephants) all with way down to The Great Turtle, but it's rapidly turning into a Norse Mythology themed name space

The object manager tentatively named "Freya" corresponds to Saci in Sputnik. It's a node manager designed to provide an object interface to values in the underlying store

I do not have a design document for Freya, yet. The general intent is that it provides fully expanded objects to the caller and minimal ("normalized") objects to Valkyrie. Operations follow the architecture intimated by the assertion that "an Activity is a delta in an ActivityStream"

Freya may have dependencies other than Valkyrie because the model benefits from optimizations like caching and indexing. Expect difficult to spell names to follow as I stay in theme. (I'm already using "vk" internally for references to Valkyrie)

Valkyrie is a low level storage API that will replace Sputnik's Versium in YAAPS and Opphuichi

The first difference is that Valkyrie has 2-way capability negotiation where Versium had a one-way capability declaration. This means that the higher level object manager will now disable unnecessary functionality in the storage module, using capabilities to enforce the principle of least privilege. So, OCaps

The second difference is that Versium was designed to track versions where Valkyrie was designed to track deltas. When I added the capability negotiation, it became apparent that Valkyrie could provide the interfaces needed for Versium as well as the ones I was designing it to support

I was planing to backport Valkyrie capabilities to Versium as a 2.0 version, but I've decided to add the capabilities in Versium objects to a Valkyrie release instead

Again, because of the licensing change

Sputnik is a wiki engine that has a really great architecture for enabling user choice. It uses infrastructure from the Kepler project similar to Rails and Python WSGI (Xavante and WSAPI)

The layered approach and plug in architecture of Sputnik did a lot to inform my opinions of "correct" approaches to software architecture, but Opphuichi was already leaning towards replacing ACLs with OCaps and eliminating the dependence on the Kepler stack before I decided to relicense it. Relicensing is just the "straw that broke the camels back" in considering a rename

Opphuichi will be a new package, not a Sputnik release. For reasons to be described shortly, data directories created in Sputnik releases prior to the fork will be transparently available to Opphuichi

YAAPS is "Yet Another ActivityPub Service"

At this point, the public facing code is mostly object hierarchies for the object classes described in the ActivityStreams 2.0 and ActivityPub specifications

The documentation describes my early intentions

The reality is that I need to build a fairly robust game server that can host player accounts, so I'll be applying those libraries to an Asynchronous framework running LuaJIT before they're used in an experimental framework where broad compatibility is important

For confusion's sake, I'm not changing the name

YAAPS and Sputnik Opphuichi are complementary approaches to getting a working ActivityPub server in Lua. Sometimes features require related infrastructure to develop; Occasionally, a clean start is better

That being the case, I need to exercise a little self care and stop being critical with myself for switching emphasis between the two projects

In order to make it easier for people to be helpful, I'm breaking both projects into smaller chunks. This means that Sputnik Neptune is going to be the last release on a permissive license. Opphuichi will be AGPL

As a prelude to updating the repos, I'm going to attempt a thread here where I describe each component

Mental health mention 

The conlang in Watership Down, Google joke 

FYI Thanks to @erbmaster and @RAPIDPUNCHES my instance now has two new corgis. One for the unset avi and one under the posting box. More corgis to come!

Show more
Banana.dog

Officially endorsed by @Gargron as a joke instance (along with freedom.horse). Things that make banana.dog unique as an instance.
- Federates with TOR servers
- Stays up to date, often running newest mastodon code
- Unique color scheme
- Strictly enforced rules
- A BananaDogInc company. Visit our other sites sites including betaMax.video, psychicdebugging and gonnaroll