How could you name this concept without using the heavily over-loaded term “app”? Like “platform”, it seems to mean something different to everyone who uses it. What “App Free Computing” suggests to me is everyone using the command line, but I’m pretty sure this isn’t what you mean.
It is a paradigm, so applying the conceptual idea in practice in the context of the use case / solution / system / software (4 words avoiding “App”) is what matters most. In tech docs I’m drafting now the term isn’t heavily advertised, just mentioned twice and explained in a brief paragraph of text. And in the glossary there’s a “words to avoid” section with:
App, Application - We move beyond the restrictive concept of “applications” where functionality is packaged in particular ways that form siloes and collaboration barriers. Use terms like “solution”, “system”, “software” or “social experience” instead.
That last term is domain-specific, as it is in the context of SX, or social experience design. We define SX as:
Design of the way people socially interact with other humans throughout the entire lifecycle and evolution of Social Web solutions.
The focus in SX is on what people need, and not how that is solidified in an “app” abstraction. On the whole choosing and then applying your terminology requires care and attention, and the it becomes easier as alternative words enter the “ubiquitous language” that’s consistently used in the scope of your solution.
There’s no such thing as universal meaning and esp. at the level of architectural concepts, every word is heavily overloaded. What e.g. is “object oriented design”? Meaning is assigned within bound contexts.
As a fun exercise, and triggered by your post, I did a search in the docs I wrote for the word “user”, and only found 2 occurrences of “user interface”. Now, “user” isn’t on the words-to-avoid list, but some time ago - inspired by Aral Balkan - I made a conscious effort to avoid it in general, and apparently succeeded as in these docs I made no deliberate effort to avoid. Instead of “user” there’s more mention of people / person(s) and explicit stakeholders (where “stakeholder” itself is in domain-specific use - SX aims to satisfy the needs of all stakeholders - and we discern stakeholder groups of “client” and “creator”… which also means that “client” isn’t really available for technical use).
1 Like
So, this term of “App Free Computing” relates to stuff I posted about in Feb. 2021 in the topic From silo-first to task-oriented federated app design.
It is the idea of having finer-grained building blocks that form the social experience people have on the Fediverse. I also mentioned the term, together with SX in:
Apps are very artificial, non-inclusive abstractions that reflect the opinionated feature set its creators find important enough to add into the software.
Since writing “Reimagine Social” I am making a more deliberate effort to picture what “social” actually means. Like if you mention “social network” to any person, they immediately think of technology. Which is weird, as we do social networking since the dawn of time. And even worse is “Social Media” that has restricted our entire thinking about online social interaction to features that Big Tech platforms invented many years ago. We copy/paste these to the Fediverse and slam the label “Feature X… but decentralized” on it, and are satisfied. That is not reimagining of social, and the average non-technical person doesn’t care much about that.
Take the ActivityStreams standard. What does that name speak to us? Well, a “stream of activities”. That is very broad and universal as a concept, and something to work with. It comes close to a real-life concept. Our daily lives consist of performing all kinds of activities.
Now bring “Apps” into this picture, and hear e.g. Mastodon saying “We are only interested in a stream of Notes”. You may respond with “But can you also display my stream of Recipes that people exchange with each other?”. The answer may be “No, we are a microblogging app, duh!” or it may be “If there’s popular demand, we may consider it.” The app silo at work 
1 Like
Indeed, this became all the more obvious to me as I learned a second language. But precisely for this reason, it’s important to choose terms that reduce confusion rather than creating it.
The old “free software” vs. “open source” argument is a good example. It seems perfectly plausible to me that people genuinely wanting to mainstream software freedom were finding themselves getting tripped up by the double meaning of “free” in English, and looking for a less ambiguous term.
The fact that the Open Source Definition is essentially the same as the Debian Free Software Guidelines supports this, as does the fact that the OSI has never AFAIK approved a license that doesn’t also meet the bar set by the Free Software Definition (HoloChain’s CAL is an intriguing edge case). The fact that far more people understand the meaning of “open source”, than the “free as in freedom” meaning of “free software”, is evidence that in this rare case, Stallman was wrong.
Anyway, coming back to the point, I think the “App Free Computing” gun is pointed at the wrong target, at a deep conceptual level.
I was an advisor to the Loomio cooperative for the first few years of developing their app, and it’s very clear to me that the constraints designed into it (with a couple of exceptions later in the process) were like a fence at the top of a cliff. They were intended as guide rails to serve the people using the software, not enslave them to it. To make the app more useful to them, not make them more useful to the developers of the app.
The problem as I see it is not “apps”, in any useful sense of the word. Apps, like words in spoken language, are abstractions that package a related set of concepts, and provide a shorthand (a sound or a sequence of letters, or an app name) people can use to refer to them.
For example, “message me on Element” or “message me on Matrix”, is much easier to understand and action than “message me with software using an internet-based, server-to-server federation protocol based on HTTPS”. “Internet” itself is an example, how many people would know what you meant by “the network of networks using TCP/IP packet-switching to form a logical peer-to-peer connection between network nodes”?
The problem, as you point out, is the silo’d nature of contemporary software. Or to put it another way, its proprietary nature; the concept of software as “intellectual property” that serves its “owner”, rather than as part of a digital commons that serves the common good. The phrase “Owner Free Computing” is much closer to what you seem to mean than “App Free Computing”, although as a buzzphrase it would introduce its own set of political complications.
Maybe the problem is trying to phrase the concept based on what it’s free of, instead of what it enables instead? Something like “Free Range Computing”?
1 Like
It is worth evaluating the terminology we use. I came to a less prominent mention of “App Free Computing” after considering how it should be applied. If one has to use language such as “message me with software using an internet-based, server-to-server federation protocol based on HTTPS” then by all means use the word “App”. There are valid uses for Apps, and also imho there’s overuse of the word.
What I find important is the role that apps play by thinking about them as an abstraction. Yes, there is an “ownership” element. To take the Fediverse as an example, we see projects stacking their “Lego bricks” a particular way, and saying “this is the kit you are allowed to play with”. But it is not just ownership. The abstraction of the app is where the fault is in this example. Let me provide an analogy…
If you imagined in real life of a bar to constitute an app. That is valid. You enter there with your friends to consume the service “space to socialize and order beverages”. If you enter a supermarket storefront (another app) and say “Hey cashier, bring me a my friends your finest ale” it is clear you come for the wrong service, used the wrong app in this analogy.
Now consider the Fediverse. This indicates the world of the Social Web, and that in turn refers to the “online space where people interact and socialize”. What is a real-world analogy of the federated apps that are available to us in this context?
It is not the bar and the supermarket that we visit in a chain of activities on our daily schedule. Instead the analogy is more like: “Here’s these 10 different pairs of glasses. Each pair gives you a different view of the world, and with all of them together you can perceive the Fediverse, but you can only wear one at the time”.
In other words the abstraction of the app is wrong. To go into the realm of bar and supermarket, in Fediverse terms Mastodon and Peertube etcetera should be services that I can consume in a single consistent social experience (through an App if you are adamant to use that term 
).
1 Like
I thought the word app was a pejorative to mean unaccountable; non malleable software which deliberately performs asymmetric attacks against its users.
Im surprised that this word can even be used in this forum without harsh disciplinary responses.
1 Like
By this definition, it’s self-evident that an “app” is a very undesirable thing. But this is not what most people mean when they say “app”. Amongst other things, it can mean;
-
a piece of software on a mobile device that isn’t part of the OS, and can be swapped out for another piece; “don’t use the built-in navigation app, download the OSMAnd+ app from F-Droid”
-
the component of an online service that the end user interacts with; “The Akkoma back-end is very efficient, but the web app could use some beautification.”
-
a package of graphical software designed for the average person to use; " the back-end is amazing on the command line, but it really needs to be an app to get wider use"
-
an online service run by a particular company; " which app small we use for a voice call? What about WhatsApp?"
I’m assuming it’s this last definition that gave rise to the phrase “App Free Computing”. But that isn’t what anyone means by “app” in the context of the verse. Which is, by that last definition “App Free Computing”.
In summary, I think this extension of the critique of proprietary computing, to a world where developers and ‘people who use’ are not (always) the same people, is valid and important. But calling it “App Free Computing”, at all, guarantees you will spend more time explaining and defending the terminology than discussing the critique. Again, a better phrase is needed to express it.
3 Likes
To be clear, we agree about the nature of the problem; the application (there’s that word again) of product design to social software. What we’re working through here is the best way to communicate that problem to developers and the communities that support them.
To stick with the bar analogy, I’d say that the verse is one giant bar, and the different apps are the drinks available. There’s beer (GNU social), wine (Mastodon), bourbon and coke (Pler/Akkoma), scotch (FireFish), Tequila shots (Lemmy/ KBin), and a range of cocktails (FunkWhale, PeerTube, OwnCast etc). Beer used to be the most popular, then wine took over as the drink of choice, but there’s always a few people who get together to drink the others, which is why the bar still stocks them.
Depending on what you drink, you’ll tend to gravitate to a certain corner of the bar, frequented by others who drink the same thing. But you always have the choice to approach anyone, anywhere in the bar and offer them a drink of their choice.
The role that ActivityPub plays here is analogous to the “money” protocol in a real bar. Whatever someone wants to drink, you can use money to buy them one. Whatever app they use, you can use ActivityPub to interact with them.
To translate your criticism into my version of the analogy, you’re saying that once we walk into the bar and order a wine, we’re stuck drinking wine all night. Which makes it harder to interact with the hipsters still drinking beer, or the people drinking whiskey and doing shots.
As you’ve said, as C Webber has said on a number of occasions, the obvious solution is for all the apps to implement a C2S protocol that allows one fediverse account to sign into any fediverse app. So that we can switch from beer to whiskey, or from wine to shots, at any time. So why are the app developers not doing that, and how might we convince them it’s worth the effort?
I recently started a thread in the verse on the limitations of the C2S part of the AP spec, and how that’s limited adoption. I think actively pushing for the documentation of Fediverse Ideas and FEPs that address this might help us push towards a bar we can all drink whatever we feel like in the moment ; )
2 Likes
This is what we want the Fediverse to be. If I briefly jump into an analogue with the hypothetical Metaverse, what I would get instead is I hit an invisible boundary and have to change to different VR goggles to be able to continue, and vice versa when going back in the part of the bar I am longer able to perceive.
But as I tooted just now to @helge there’s many analogies to make and different ways to look at things.
What I wanted to express is that the current way the fedi evolves doesn’t lead to my online world being a good extension of my offline world. I get a yanky experience. The Fediverse universe, or bar, whatever is mostly theoretical. Our shared dream.
Yes. In our case, it is like “the world as shaped by a particular (FOSS) development team in their project”.
As you say, indeed C2S would be on the path towards more integrated social experiences on the Fediverse. A C2S client being a single pair of glasses to perceive the online world.
But another need is objects in that world, where we can build with, like in Minecraft. A more component-based and service-oriented Fediverse that allows choreographing of the social experience, and indeed - as @indieterminacy mentioned - facilitates a certain malleability to each fedizen to customize as they wish.
Heterogenous Fediverse: Components & services
Just for shits and giggles, I drew an example occurence that one might one day see on a Mastodon timeline, in a more heterogenous Fediverse:
This is still very much a UI sketch as a microblogging app might present it. A different (C2S) client may have a completely different representation, and may for example drop the notion of a Timeline altogether. In this presentation the Group, the Event, and the Recipe might’ve been provided by separate independent services that are combined. And none of those by Mastodon.
The various widgets in this timeline section may have their own business logic and side effects. Many incoming msgs need not lead to additional timeline additions, but could just be dynamically updating a widget that was received earlier.
Update: There’s a bug in my sketch. To the toot about it I added:
Oops… there’s a bug in the software and Cassandra bringing 28 oranges is double posted.
I might draw another sketch showing Sandra sending a Support ticket to @JoinMyMeal service provider.
But I am lazy and Sandra is busy organizing that party…
1 Like
Except for the little box marking what kind of Activity each post is, I can’t see what makes this different from an existing timeline on Mastodon (or any other fedi app). For me, the chronological timeline itself is a pair of glasses, one that heavily limits my view of the total activity space that is the verse.
Contrast this with the way FB (circa 2010) allowed me to toggle between my my wall, my messages, my events etc, all within one app.
1 Like
Yep, the timeline is a pair of glasses. I drew my quick sketch to be familiar to those using Mastodon and similar timeline UI’s. You can go any direction you want UI/UX-wise. And here we get to a point where the analogy becomes strained. It is the data you receive from the Fediverse that determines your “worldview”, the completeness of your overview. The UI/UX are then more like the colors of your glasses, that allow you to see the same world in different colors.
In that timeline there are custom types with their own dynamic widgets delivered and still managed by 3rd-party providers, and you don’t have to beg BDFL’s on an app-by-app basis for 4 years to please include native support for your custom type. Which, btw, understandably these BDFL’s are reluctant to implement. It is simply not their “core business”, which is their own app and its use case / objectives.
Update: Some related thoughts on this in Thoughts on Actor Model versus Fediverse - #4 by aschrijver
1 Like