Tech

By Johannes Ernst

https://reb00ted.org/tech/

  • 2021-11-29

    Facebook’s metaverse pivot is a Hail Mary pass

    Update Feb 04, 2022: It looks like I was entirely correct with this November post. Facebook is out of new users, over 10 billion in metaverse investments have nothing to show for it yet, and the markets have caught up, dropping the stock by $200 billion in a day. To make things worse, Zuckerberg supposedly said “focus on video” in the all-hands on the same day. He chickened out; he should have doubled down on the metaverse story if he truly believes it. But he did not.

    The more I think about Facebook’s Meta’s pivot to the metaverse, the less it appears like they do this voluntarily. I think they have no other choice: their existing business is running out of steam. Consider:

    • At about 3.5 billion month active users of at least one of their products (Facebook, Instagram, Whatsapp etc), they are running out of more humans to sign up.

    • People say they use Facebook to stay in touch with family and friends. But there is now one ad in my feed for each three or four posts that I actually want to see. Add more ads than this, and users will turn their backs: Facebook doesn’t help them with what they want help with any more, it’s all ads.

    • While their ARPU is much higher in the US than in Europe, where in turn it is much higher than the rest of the world – hinting that international growth should be possible – their distribution of ARPU is not all that different from the whole ad market’s distribution of ad revenues in different regions. Convincing, say, Africa to spend much more on ads does not sound like a growth story.

    • And between the regulators in the EU and elsewhere, moves to effectively ban further Instagram-like acquisitions, lawsuits left and right, and Apple’s privacy moves, their room to manoever is getting tighter, not wider.

    Their current price/sales ratio of just under 10 is hard to be justified for long under these constraints. They must also be telling themselves that relying on an entirely ad-based business model is not good long-term strategy any more, given the backlash against surveillance capitalism.

    So what do you do?

    I think you change the fundamentals of your business at the same time you change the conversation, leveraging the technology you own. And you end up with:

    • Oculus as the replacement for the mobile phone;

    • Headset and app store sales, for Oculus, as an entirely new business model that’s been proven (by the iPhone) to be highly profitable and is less under attack by regulators and the public; it also supports potentially much higher ARPU than just ads;

    • Renaming the company to something completely harmless and bland sounding; that will also let you drop the Facebook brand should it become too toxic down the road.

    The risks are immense, starting with: how many hours a day do you hold your mobile phone in your hand, in comparison to how many hours a day you are willing to wear a bucket on your head, ahem, a headset? Even fundamental interaction questions, architecture questions and use case questions for the metaverse are still completely up in the air.

    Credit to Mark Zuckerberg for pulling off a move as substantial as this for an almost trillion dollar company. I can’t think of any company which has ever done anything similar at this scale. When Intel pivoted from memory to CPUs, back in the 1980’s and at a much smaller scale, at least it was clear that there was going to be significant, growing demand for CPUs. This is not clear at all about headsets beyond niches such as gaming. So they are really jumping into the unknown with both feet.

    But I don’t think any more they had a choice.

  • 2021-11-15

    Social Media Architectures and Their Consequences

    This is an outcome of a session I ran at last week’s “Logging Off Facebook – What comes next?” unconference. We explored what technical architecture choices have which technical, or non-technical consequences for social media products.

    This table was created during the session. It is not complete, and personally I disagree with a few points, but it’s still worthwhile publishing IMHO.

    So here you are:

    Facebook-style ("centralized") Mastodon-style ("federated") IndieWeb-style ("distributed/P2P") Blockchain-style
    Moderation Uniform, consistent moderation policy for all users Locally different moderation policies, but consistent for all users on a node Every user decides on their own Posit - algorithmic smart contract that drives consensus
    Censorship easy; global one node at a time full censorship not viable full censorship not viable
    Software upgrades Fast, uncomplicated for all users Inconsistent across the network Inconsistent across the network Consistent, but large synchronization / management costs
    Money Centralized; most accumulated by "Facebook" Donations (BuyMeACoffee, LiberaPay); Patronage (Patreon) Paid to/earned by network nodes; value fluctuates due to speculation
    Authentication Centralized Decentralized (e.g. Solid, OpenID, SSI) Decentralized (e.g. wallets)
    Advertising Decided by "Facebook" Not usually Determined by user
    Governance Centralized, unaccountable Several components: protocol-level, code-level and instance-level Several components: protocol-level, code-level and instance-level
    Search & Discovery
    Group formation
    Regulation
    Ownership Totalitarian Individual
  • 2021-10-11

    It’s been 15 years of Project VRM: Here’s a collection of use cases and requirements identified over the years

    Today’s Project VRM meeting marks the project’s 15 years anniversary. A good opportunity to list the uses cases that have emerged over the years. To make them more manageable, I categorize them by the stage of the relationship between customer and vendor:

    Category 1: Establishing the relationship

    What happens when a Customer or a Vendor wishes to initiate a relationship, or wishes to modify the terms of the relationship.

    1.1 Customer initiates a new relationship with a Vendor

    “As a Customer, I want to offer initiating a new relationship with a Vendor.”

    Description:

    • The Customer encounters the Vendor’s electronic presence (e.g. their website)
    • The Customer performs a gesture on the Vendor’s site that indicates their interest of establishing a relationship
    • As part of the gesture, the Customer’s proposed terms are conveyed to the Vendor
    • In response, the Vendor provides acceptance of the proposed relationship and offered terms, or offers alternate terms in return.
    • If the offered terms are different from the proposed terms, the Customer has the opportunity to propose alternate terms; this continues until both parties agree on the terms or abort the initiation.
    • Once the terms have been agreed on, both sides record their agreement.

    Notes:

    • To make this “consumer-grade”, much of the complexity of such concepts as “proposed terms” needs to be hidden behind reasonable defaults.

    1.2 Vendor initiates a new relationship with a Customer

    “As a Vendor, I want to offer initiating a new relationship with a Customer.”

    Similar as for “Customer initiates a new relationship with a Vendor”, but with reversed roles.

    1.3 Customer and Vendor agree on a closer relationship

    “The Customer and the Vendor agree on a closer relationship.”

    Description:

    • The Customer and the Vendor have been in a relationship governed by certain terms for some time.
    • Now, either the Customer or the Vendor propose new terms to the other party, and the other party accepts.
    • The new terms permit all activities permitted by the old terms, plus some additional ones.

    Example:

    • The Customer has agreed with the Vendor that the Vendor may send the Customer product updates once a month. For that purpose, the Customer has provided Vendor an e-mail address (but no physical address).
    • Now, the Customer has decided to purchase a product from Vendor. To ship it, the Vendor needs to have the Customer’s shipping address. New terms that also include the shipping address are being negotiated.

    1.4 A Customer wants a more distant relationship

    “As a Customer, I want to limit the Vendor to more restrictive terms.”

    Description:

    • The Customer and the Vendor have been in a relationship governed by certain terms for some time.
    • Now, the Customer wishes to disallow certain activities previously allowed by the terms, without terminating the relationship.
    • The Customer offers new terms, which the Vendor may or may not accept. The Vendor may offer alternate terms in turn. This negotiation continues until either mutually acceptable terms are found, or the relationship terminates.

    Examples:

    • The Customer has agreed with the Vendor that the Vendor may send the Customer product updates. Now the Customer decides that they do not wish to receive product updates more frequently than once a quarter.
    • The Customer has agreed to behavioral profiling when visiting Vendor’s website. Now, while the Customer still wishes to use the website, they do no longer consent to the behavioral profiling.

    2. Category: Ongoing relationship

    What happens during a relationship after it has been established and while no party has the intention of either modifying the strength of, or even leaving the relationship.

    2.1 Intentcasting

    “As a Customer, I want to publish, to a selection of Vendors that I trust, that I wish to purchase a product with description X”

    Benefits:

    • Convenience for Customer
    • Potential for a non-standard deal (e.g. I am a well-known influencer, and the seller makes Customer a special deal)

    Features:

    • It’s basically a shopping list
      • free-form text
      • plus “terms” (FIXME: open issue)
    • Retailers can populate product alternatives for each item in the list
      • might simply be a search at the retailer site
      • but terms need to be computable

    Issues:

    • what if a retailer lies and spams with unrelated products, or unavailable products?

    2.2 Automated intentcasting on my behalf

    “As a Customer, I want an ‘AI’ running on my behalf to issue Intentcasts when it is in my interest”

    Description:

    • This is similar to functionality deployed by some retailers today: “We noticed you have not bought diapers in the last 30 days. Aren’t you about to run low? Here are some offers”. But this functionality runs on my behalf, and takes data from all sorts of places into account.

    Benefits:

    • Convenience, time savings

    2.3 Contextual product reviews and ratings

    “As a Customer, I want to see reviews and ratings of the product and seller alternatives for any of my shopping list items.”

    Benefits:

    • Same as product reviews in silos, but without the silos: have access to more reviews and ratings by more people
    • Seller alternatives give Customer more choice

    2.4 Filter offers by interest

    “As a Customer, I want to receive offers that match my implicitly declared interest”

    Description:

    • In Intentcasting, I actively publish my intent to meet a need I know I have by purchasing a product
    • This is about offers in response to needs, or benefits, that I have not explicitly declared but that can be inferred. Example: if I have purchased a laser printer 6 months ago, and I have not purchased replacement toner cartridges nor have I declared an intent to purchase some, I would appreciate offers for such toner cartridges (but not of inkjet cartridges)

    Benefits:

    • Convenience for Customer
    • Better response rate for Vendor

    2.5 Full contact record

    “As a Customer, I want a full record of all interactions between Customer and each Vendor accessible in a single place.”

    Benefits:

    • Simplicity & Convenience
    • Trackability
    • Similar to CRM

    Notes:

    • This should cover all modes of communication, from e-mail to trouble tickets, voice calls and home visits.

    2.6 Manage trusted Vendor’s in a single place

    “As a Customer, I want to see and manage my list of trusted Vendors in a single place”

    Benefits:

    • Simplicity
    • Transparency (to Customer)

    Notes:

    • Probably should also have a non-trusted Vendor’s: so my banned vendors are maintained in the same place — which subset is being displayed is just a filter function
    • Probably should have a list of all Vendor’s ever interacted with

    2.7 Notify of changes about products I’m interested in

    “As a Customer, I want be notified of important changes (e.g. price) in products that I’m interested in.”

    Benefits:

    • can use my shopping cart as a “price watch list” and purchase when I think the price is right

    Notes:

    • This should apply to items in my shopping cart, but also items in product lists that I might have created (“save for later” lists)

    2.8 Personal wallet

    “As a Customer, I want my own wallet that I can use with any Vendor”

    Benefits:

    • Simplicity & Convenience
    • Unified billing

    Notes:

    • Unified ceremony
    • Should be able to delegate to the payment network of my choice

    2.9 Preventative maintenance

    “As a Customer, I would like to be notified of my options when a product I own needs maintenance”

    Description:

    • If I have a water heater, and it is about to fail, I would like to be notified that it is about to fail, with offers for what to do about it. It’s a kind of intentcasting but the intent is inferred from the fact that I own the product, the product is about to fail, that I don’t want it to fail and I am willing to entertain offers from the vendor I bought it from and others.

    Benefits:

    • Convenience for Customer
    • No service interruption

    2.10 Product clouds

    “Each product instance has its own cloud”

    Benefits:

    • Collects information over the lifetime of the product instance
    • Product instance-specific
    • Can change ownership with the product
    • Does not disappear with the vendor

    Example:

    • My water heater has its own cloud. It knows usage, and maintenance events. It continues to work even if the vendor of the water heater goes out of business.

    2.11 Product info in context

    “As a Customer, I want to access product documentation, available instruction manuals etc in the context of the purchase that I made”

    Benefits:

    • Simplicity & Convenience
    • Updated documentation, new materials etc show up automatically

    2.12 Set and monitor terms for relationships

    “As a Customer, I want to set terms for my relationship with a Vendor in a single place”

    Benefits:

    • Simplicity & Convenience
    • Privacy & Agency

    Notes:

    • Originally this was only about terms for provided personal data, but it appears this is a broader issue: I also want to set terms for, say, dispute resolution (“I never consent to arbitration”) or customer support (“must agree to never let Customer wait on the phone for more than 30min”)

    2.13 Update information in a single place only

    “As a Customer, I (only) want to update my personal contact information in one place that I control”

    Benefits:

    • for Customer: convenience
    • for Vendor: more accurate information

    Issues:

    • Should that be a copy and update-copy process (push), or a copy and update-on-need process (pull with copy) or a fetch-and-discard process (pull without copy)?

    Notes:

    • Originally phrased as only about contact info (name, married name, shipping address, phone number etc) this probably applies to other types of information was well, such as, say, credit card numbers, loyalty club memberships, even dietary preferences or interests (“I gave up stamp collecting”)

    2.14 Single shopping cart

    “As a Customer, I want to use a single shopping cart for all e-commerce sites on the web.”

    Benefits:

    • I don’t need to create accounts on many websites, or login into many websites
    • I decide when the collection of items in the cart expires and I don’t lose work
    • It makes it easier for Customer to shop at more sites, and I can more easily buy from the long tail of sites

    Features:

    • It shows product and seller
    • It may show alternate sellers and difference in terms (e.g. price, shipping, speed)
    • We may also want to have product lists that aren’t a shopping cart (“save for later” lists)

    2.15 Unified communications/notifications preferences

    “As a Customer, I want to manage my communication/notification preferences with all Vendors in a single place”

    Notes:

    • In a single place, and in a single manner. I should not have to do things differently to unsubscribe from the product newsletter of vendors X and Y.

    Benefits:

    • Simplicity & Convenience

    2.16 Unified product feedback

    “As a Customer, I want a uniform way to submit (positive and negative) product feedback (and receive responses) with any Vendor”

    Benefits:

    • Simplicity & Convenience
    • Trackability
    • Similar to CRM

    Notes:

    • Should be easy to do this either privately or publicly

    2.17 Unified purchase history

    “As a Customer, I want to have a record of all my product purchases in a single place”

    Benefits:

    • Simplicity & Convenience
    • If I wish to re-order a product I purchased before, I can easily find it and the vendor that I got it from

    2.18 Unified subscriptions management

    “As a Customer, I want to manage all my ongoing product subscriptions in a single place”

    Benefits:

    • Simplicity & Convenience
    • Expense management

    Note:

    • This is implied by the source, not explicitly mentioned.

    Future:

    • Opens up possibilities for subscription bundle business models

    2.19 Unified support experience

    Benefits:

    • Simplicity & Convenience
    • Trackability
    • Similar to CRM

    Notes:

    • Should be multi-modal: trouble tickets, chat, e-mail, voice etc

    3. Category: Beyond binary relationships

    Use cases that involve more than one Customer, or more than one Vendor, or both.

    3.1 Proven capabilities

    “As a Vendor, I want to give another party (Customer or Vendor) the capabilities to perform certain operations”

    Description:

    • This is SSI Object Capabilities
    • Example: I want to give my customer the ability to open a locker
    • The scenario should be robust with respect to confidentiality and accuracy.

    3.2 Silo-free product reviews

    “As a Customer, I want to publish my reviews and ratings about products I own so they can be used by any other Customer at any point of purchase”

    Benefits:

    • Same as product reviews in silos, but without the silos: broader distribution of my review for more benefit by more people

    Notes:

    • Rephrased from “express genuine loyalty”

    3.3 Monitoring of terms violation

    “As a Customer, I want to be notified if other Customer’s interacting with a Vendor report a violation of their terms”

    Description:

    • I have a relationship with a Vendor, and we have agreed to certain terms. If the Vendor breaks those terms, and other Customer’s in a similar relationship with the Vendor notice that, I want to be notified.

    Benefits:

    • Trust, security, safety

    Notes:

    • This can of course be abused through fake reports, so suitable measures must be taken.

    3.4 Unified health and wellness records

    “As a Customer, I want my health and wellness records from all sources to be aggregated in a place that I control.”

    Benefits:

    • Survives disappearance of the vendor
    • Privacy
    • Allows cross-data-source personal analytics and insights
    • Integration across healthcare (regulated industry) and wellness (consumer)

    3.5 Verified credentials

    “As a Customer, I want to be able to tell Vendor 1 that Vendor 2 makes a claim about Customer.”

    Description:

    • This is the SSI verified credential use case
    • Example: I want to tell a potential employer that I have earned a certain degress from a certain institution
    • The scenario should be robust with respect to confidentiality and accuracy.

    4. Category: Ending the relationship

    What happens when one of the parties wishes to end the relationship.

    4.1 Banning the vendor

    “As a Customer, I want to permanently ban a Vendor from doing business with Customer ever again.”

    Description:

    • This form of ending the relationship means that I don’t want to be told of offers or responses to Intentcasts etc. by this vendor ever again.

    4.2 Disassociating from the vendor

    “As a Customer, I want to stop interacting with a vendor at this time but I am open to future interactions.”

    Description:

    • This probably means that data sharing and other interaction reset to the level of how it was before the relationship was established. However, the Customer and the Vendor do not need to go through the technical introduction ceremony again when the relationship is revived.

    4.3 Firing the customer

    “As a Vendor, I want to stop interacting with a particular Customer.”

    Description:

    • For customers (or non-customers) that the Vendor does not wish to serve (e.g. because of excessive support requests), the VendorVendor may unilaterally terminate the relationship with the Customer.
  • 2021-10-08

    What is the metaverse? A simple definition.

    Mark Zuckerberg recently dedicated a long interview to the subject, so the metaverse must be a thing. Promptly, the chatter is exploding. Personally I believe the metaverse is currently underhyped: it will be A Really Big Thing, for consumers, and for businesses, and in particular for commerce and collaboration, far beyond what we can grasp in video games and the likes today.

    So what is it, this metaverse thing? I want to share my definition, because I think it is simple, and useful.

    It’s best expressed in a two-by-two table:

    How you access it:
    physically vs. virtually
    Where it is:
    in physical or virtual space
    The virtual world, accessed physically:
    Augmented Reality
    The virtual world, accessed virtually:
    today's internet and future virtual worlds
    The physical world, accessed physically:
    our ancestors exclusively lived here
    The physical world, accessed virtually:
    the Internet of Things

    By way of explanation:

    • There is physical space – the physical world around us – and virtual space, the space of pure information, that only exists on computers.

    • Our ancestors, and we so far, have mostly been interacting with physical space by touching it physically. But in recent decades, we have learned to access it from the information sphere, and that’s usually described as the Internet of Things: if you run an app to control your lights, or open your garage door, that’s what I’m talking about.

    • So far, we have mostly interacted with virtual space through special-purpose devices that form the gateway to the virtual space: first computers, now phones and in the future: headsets. I call this accessing virtual space virtually.

    • And when we don our smart glasses, and wave our arms, we interact with virtual space from physical space, which is the last quadrant.

    In my definition, those four quadrants together form the metaverse: the metaverse is a superset of both meatspace and cyberspace, so to speak.

    This definition has been quite helpful for me to understand what various projects are working on.

  • 2021-09-04

    Today’s apps: context-free computing at its finest

    Prompted by this exchange on Twitter:

    Let me unpack this a bit. Let’s say that I’d like to send a message to some guy, let’s call him Tom for this example.

    The messaging app vendors go like: “Oh yes, we’ll make it super-easy for him (Johannes) to send a message to Tom, so we give him an extra short handle (say @tom) so he doesn’t need to type much, and also add a ‘reply’ button to previous messages so he won’t even have to type that.”

    Which is myopic, because it completely misunderstands or ignores the context of the user. The user doesn’t think that way, at least most of the time.

    As a user, I think the pattern is this:

    “I need to tell (person) about (news) related to (common context), how do I best do that (i.e. which app)?”

    Three concepts and a sub-concept:

    • Who do I want to tell. In Joshua’s example: the person(s) I’m about to meet with.

    • What’s the news I want to tell them. Here it is “I am running late”.

      • But this news only makes sense in the common context of “we agreed to meet today”. If the receiver doesn’t have that context, they will receive my message and it will be pointless and bewildering to them.
    • What’s the best way of conveying that news. It might be a text, a phone call, or pretty much anything. This item is the least important in this entire scenario, as long as the receiver gets the message.

    So thre are two primary “entry” points for this scenario:

    1. It starts with a person. The user thinks “Tom, I need to tell Tom that I’ll be late”, and the frantically tries to find a way of contacting them while hurring in the subway or driving really fast. (We have all been there.)

    2. It starts with the shared context object. The user looks at the calendar and thinks “Oh darn, this meeting, it’s now, I’ll be late, I need to tell them”. (They might not even remember who exactly will be in the meeting, but then likely the calender event has that info.)

    The entry point is almost never: “how convenient, I have all people I’m about to meet with in the current window of the messaging app, they all know what whatever I’m going to type into that window next is about the meeting, and I can just simply say that I’ll be late.”

    So … if we were to put the user, and their experience, at the center of messaging, messaging wouldn’t be an app. (Well, it might also be an app, but mostly it wouldn’t.)

    Instead, the messaging would be a “system service” attached to the context objects in which I’d like to message. In Joshua’s example that is:

    • the person I’m about to meet with (but this only works if there is a single person; if there are a dozen this does not work).

    • the shared context about which I am conveying the news: here, the (hopefully shared) calendar event. Joshua’s original point.

    Now in my experience, this is just an example for a more general pattern. For example:

    • meeting notes. In which meeting any meeting notes were taken is of course supremely important. Which is why most meeting minutes start with a title, a date/time and a list of attendees. Instead, they should be attached to the calendar event, just like the message thread. (Yes, including collaborative editing.)

      And by “attached” I don’t mean: there’s a URL somewhere in the calendar dialog form that leads to a Google Doc. No, I mean that the calendar can show them, and insert the to-do-items from the meeting, and future meetings from that document, and the other way around: that when you look at the meeting notes, I can see the calendar event, and find out it is a biweekly meeting, and the notes for the other meetings are over there.

    • projects. Software development is the worst offender, as far as I know. If you and I and half a dozen other people work on a project to implement functionality X, that is our primary shared context. All communication and data creation should occur in that context. But instead we have our code in Github, our bugs in Confluence, our APIs … test cases … screen mockups … video calls … chats … in a gazillion different places, and one of these days I’m sure somebody is going to prove that half of software budgets in many places are consumed by context switching between tools that blissfully ignore that the user thinks not like a vendor does. (And the other half by trying to make the so-called “integrations” between services work.)

    There are many more examples. (In a previous life, I ran around with the concept of “situational computing” – which takes context-aware computing to something much more dynamic and extreme; needless to say it was decades before its time. But now with AR/VR-stuff coming, it will probably become part of the mainstream soon.)

    The 100 dollar question is of course: if this is the right thing for users, why aren’t apps doing that?

    Joshua brought up OpenDoc in a subsequent post. Yep, there is a similarity here, and apps don’t do this kind of thing for the same reason OpenDoc failed. (It didn’t fail because it was slow as molasses and Steve Jobs hated it.)

    OpenDoc failed because it would have disintermediated big and powerful companies such as Adobe, who would have had to sell 100 little OpenDoc components, instead of one gigantic monolith containing those 100 components as a take-it-or-leave-it package at “enterprise” pricing. No adoption by Adobe, Adobe feeling Apple proactively attacked their business model, it would have killed Apple right afterwards.

    But having OpenDoc would have sooo much better for users. We would have gotten much more innovation, and yes, lower prices. But software vendors, like all businesses, primarily do what is right for them, not their customers.

    Which is why we get silos everwhere we look.

    If we wanted to change that situation, about OpenDoc-like things, or messaging attached, in context, to things like calendar events, we have to change the economic situation in which the important vendors find themselves.

    Plus of course the entire technology stack, because if all you know is how to ship an int main(argv, argc) on your operating system, something componentized and pluggable and user-centric and context-centric is never able to emerge, even if you want to.

    (*) The title is meant to be sarcastically, in case you weren’t sure.