I’m convinced that aggregators of our attention cannot be remediated, they must be bypassed with a personal, federated tool for making an receiving offers (which is a recipe for building our own search engines, social networks and e-commerce sites).
I have a description of the problem and am currently writing up the solution concept here: https://offerbots.org/
I welcome your input and feedback.
Hi @AndrewMackie ,
Your concept of offerbots is intriguing. But I think I couldn’t capture the benefit in adding an additional layer of technology to interactions. How would it positively impact the current demand for our attention? Could you please clarify?
Hi @swanderl, thanks for your question. The purpose of offerbots is to shift us from an attention economy (in which we are given ‘free’ information processing in order to capture and direct our attention toward advertising) to an information economy (in which we pay for our own information processing in order to control which offers our attention is allocated to). Would you like me to elaborate on any of that?
Yes, the concept fascinates me too, to great extent. You have your thinking very clear @AndrewMackie!
I am completely sold on your description of the problem-side. It’s fantastic. Please let me ponder and speculate a bit more on the solution side. I haven’t given this enough attention yet myself, so these are raw thoughts off the top of my head, and may cover what you already wrote down elsewhere…
Convincing people to participate in a distributed network of offerbots from scratch, however, is almost impossible.
Yes, you need network effects for that. But not having these might not be as hampering as, say, leaving Facebook and in one go losing online contact with all your friends and family. There is less FOMO involved, and you can happily use OfferBots side-by-side with the old system.
The intermediate solution is to create a centralised offer processing system which is neutral and does not exclude any party on the basis of their ability or willingness to pay.
This is not really needed. A very large centralized offer processing system would be costly, and either needs to be subsidized or charge for its services which makes it vulnerable to a more competitive aggregator (if the protocol is not watertight).
The federated system will do just fine. The ideal end result would be a peer-to-peer network where everyone has their own offer processor, but that will probably never happen. Instead start with the model you suggested where “each person or organisation hosts (or pays to have hosted)” their offers.
The federated servers constitute centralization points, or Hubs, and the individual processors are Endpoints.
This is no different to how the fediverse currently works (and also Secure Scuttlebutt, which is mixed p2p / federated, and others). Note that there is always a tendency and risk for centralization to occur (like in the fediverse where mastodon.social is by far the largest instance), after which that hub starts to create vendor lock-in, and eventually forms a ‘de-facto’ walled garden with network effects working in its favor (e.g. Gmail).
On the fediverse this is mitigated by:
Like the fediverse many parties are incentivised to run a Hub and provide access without cost. NGO’s, political parties, special interest groups, etc. On the fediverse you have e.g. social.coop (for cooperatives), fosstodon (spreading FOSS mindset), queer.party (LGBT+). But also any other business, vendors and shops. They may cough up the cost, and incorporate it in the price of the offers (this will be like e.g. 0.001 ct per offer, like micropayment). Of course they can also have other payment models, like subscription-based pricing.
(Btw, note that the fediverse ActivityPub specification allows there to be a mixed federated and peer-to-peer model in the future).
Offerbots provide external offer processing by:
- […]
- applying processing (algorithms) to stored offers in order to filter and prioritize offers, and
- representing a subset of received offers to its owner (you) using any format (a web page, email, text, app view, app notification, etc.).
Yes, but also you set your filter beforehand to only receive a small subset of offers to process and filter afterwards. Your filter broadcasts your ‘default’ interest so you don’t miss out on interesting offers.
Interesting to note that in order to expose your interest filter you could broadcast ‘Offers to receive Offers’. This is confusing, so you might introduce the ‘Request for Offer’ or ‘Offer Request’ terminology (but it is still an offer type).
This also reduces network bandwidth and with all Endpoints acting together it is a natural filter for unwanted offers. There are all kinds of mechanisms to do this. While important information may be gossipped to become generally available (hosted on many Hubs and Endpoints), other offers will only be hosted shared after you showed an interest for it (similar to PeerTube, where you have a link aggregator to video’s and when watching, you become a node where others can stream from).
Interesting is that you might not want to share many of the offers you get. When booking a vacation or reserving a seat in the cinema I have no interest to share the offer, as the price will rise or the show is sold out.
[Offers] can be shared with other offerbots via the web and other protocols as needed (e.g. BLE for making and receiving offers locally).
Note that in a peer-to-peer system, in order to reach Endpoints that are on a private network and behind a firewall, you either need a server host within the network (what Secure Scuttlebutt is doing) or you need to do NAT traversal (what e.g. Dat Foundation is doing).
Offers may be made publicly or privately with any party and are signed for authenticity.
This means that in many cases they will be both signed and encrypted, or partially encrypted (e.g. having a public header and encrypted PII).
Offerbots, therefore, need to operate at a different layer to browsers. They will:
- use the web to send and receive tens, hundreds or thousands of offers with offerbots (through web APIs),
- filter, score and rank received offers (according to its owners preferences), and
- act as a publisher by generating maps (web documents, emails, app views, notifications, etc.) which represent offers to their owner and their choice of other people (through a browser, email program, app, etc.).
Up to this point, and reading the above it is clear to me that there is still a huge market for aggregators to exist. But I agree with you that parts of the problem aggregators cause, can be mitigated. There is a lot to analyse still, and that takes a concerted effort. We have to avoid having commercial interests go loose with this whole idea, before we have a change to fill in the gaps, or in a couple of years we are at the same point where we are now.
Some more technical points:
@tag42git described it to me “a way to set read and write permissions for the giant global graph, the web”.
The SWOT should be further elaborated, but I leave it with this for now 
Hi,
I’m new to this forum. Thanks to @aschrijver, who recommended it. I usually hang out on the Solid forum.
I’ve been reading about offerbots, and they sound really interesting! As Arnold mentioned, there are some synergies with Solid. Solid at this stage is more of a pubsubhub for data without being an active server, but I believe that is planned, although it may take a while to get there. I also think linked data will be very important. Its adoption is I think greater than people think. IIRC, the biggest repository of linked data is Facebook itself with foaf graphs.
The info on offers and attention and aggregators is very interesting. I’m still going through it.
It seems to proceed from some assumptions, though, that I’m not sure I share. One is that to scale is good. I’m not so sure. If I have a virtual assistant, say its a little like Siri or Alexa but way smarter and ideally built from the ground up as open source and free software, I probably would use it for a few things.
I could point it to a list of my favorite news sites and have it filter the news for me according to my very particular custom filters. I could have it listen to my conversations and organize them by topic and respond to requests I make for more information. I could have it translate things.
But I don’t think I would want it filtering and comparing offers from all over the place in the background. Only when I asked it to, would I want that. So I would start from a more local first kind of perspective.
I really liked the detailed analysis of the economics of aggregators. People have many motivations ranging from good to bad and money is only one of them. This is lost in todays take no prisoners capitalist society. In other words, aggregators do not have to be profit maximizing.
I’ll keep reading, and will stay tuned 
Thank you for taking time to explain that! I appreciate that.
Thanks @aschrijver for investing that time into your reply.
Don’t be too impressed by my ability to think clearly on offerbots - I’ve spent a decade thinking about them (and am embarrassed by how long it’s taken me to clarify my thinking).
I’m not convinced that building the tool and a federated system is a viable starting point. The fediverse has 484k monthly active users (according to https://the-federation.info/). By almost any measure that’s a cracking success. The problem is that the only measure which counts is the monthly active users of Facebook which stands at 2.6B - the fediverse is 0.01% of the size.
If the goal for offerbots were to create a viable alternate economy for the rebels I’d be happy with that, but my goal is to bypass the Empire.
There are a number of key challenges in this project, none of which are solved by building the tool itself as a federated system (without a centralised starting point).
The first is the network effects, as you noted. But it’s much harder than creating one network - you need to create two networks on both sides of the market (the vendor side and the buyer side). And it’s much harder than that again, because you need to create networks on both sides of every market (not just one market). Put bluntly, launching offerbots requires world-class execution. (Strictly speaking, offerbots treat everyone as a peer. There are no ‘consumers’ who do nothing but consume - anyone can make and receive offers of any kind, but people will remain in their ‘consumer’ and ‘vendor’ roles until they realise they can do more). Regardless, someone or something needs to bring the offers and/or the people together to make offerbots worth using. Simply creating the federated tool does not achieve this.
The second key challenge is convincing consumers to pay for something that they currently get for free. Or, at least, that they think they get for free. At the moment they get convenience for free, which is a form of efficiency in which control is withheld by the giver (i.e. the user can easily find offers, as long as they’re the offers that the aggregator wants them to see). That’s like giving people a free car as long as it drives only to the stores of advertisers. That feels pretty amazing until you taste genuine efficiency in which you control how the efficiency is used (and can drive your car anywhere you please). That’s worth paying for. Perhaps another analogy is Mark Zuckerberg’s ‘free’ Internet Basics (that he tried to fool India into taking up) compared to paying for genuine internet access. We’re all happy to pay for the internet because it offers genuine freedom in how we use it.
All of that said, I think that the solution is to do both at once - to simultaneously build a federated system while using one or more benign aggregators to solve the chicken and egg problem
What I meant in ‘offers to receive offers’ is that there is a second-order effect that can be used here. That is, my offerbot does not need to act alone - it can collect offers and sell the result set of offers to others, or buy results from others. I imagine supernodes which have a reputation for having all of the houses for sale in a particular city, say, and receive money to deliver that set. Given that others can also collect the same set, they cannot act as monopolists but must compete on price.
This is how offerbots can be both distributed and decentralized.
Yes. It’s not clear enough yet.
All Linked Data has done so far is make the aggregators more efficient. Until the public have their own tools for making and processing Linked Data (rather than browsers which merely represent web pages as their publishers intended) nothing will change.
As a noob to the fediverse, I welcome guides such as yourself.
The problem with distributed systems to date is that they are have not been generalised at the right level. The right level is not apps, it’s offers.
Thanks again.
Well, at least we both have the complexity in well enough perspective, ha ha. Yes, it is as complex as you describe, and probably way more complex still.
Since I’m also an embarrassing small guy 
in light of of these giant efforts that are needed, I will tackle this on the smallest scale and not involve myself with bringing all these bright minds together to go from the other end (supposing they even want to listen to me). I have some interesting use cases in a hobby project I’m working on, that operate at that small scale, but that are also scaleable… and federated.
I would be happy if you join me on the quest of discovery here
The deeper levels are more fine-grained than offers. You are talking messages, data chunks, and streams of data at internet protocol level or other levels still below where offers are defined, I think. So that should not be a problem.
Deam big, act small.
I created a post on SocialHub to discuss implementation of Offers in the fediverse, where subsequently a great discussion ensued between @AndrewMackie and @cjs, developer of Go-Fed activitypub library, and a Google Technical Engineer working from Zürich. Highly recommended read…