How would this be tooled? A chargeback, a deep link to the cancel page, an API connection between bank and subscription?
Chargeback is easy because it's under the card co's control. Deep link would require knowing the cancel page of every sub, plus handling auth factors. API connection would two way integration, with scoped auth between every bank and every service. Hopefully managed by an SI or aggregator, but the business model sounds hard (the bank doesn't mind the chargeback, the SaaS doesn't want the cancelation, so who pays?)
Visa/MasterCard/Amex already support such a facility in India due to RBI requirements. Doesn't seem too difficult to adapt similar functionality for other countries too, if the regulations are updated to require it.
> How would this be tooled? A chargeback, a deep link to the cancel page, an API connection between bank and subscription?
I'd be happy to just have the ability to easily ask the credit card company block further payments with no actual notification to the business besides that the monthly charges stop going through. If you want to be fancy about it, creat a custom industry standard declination reason for that use case.
Considering they are placing the charges in the first place, it would seem like it would just need to be a response code, not a convoluted network of extensive new development like you suggest.
Integrations are usually one-way (merchant calls bank API), but it's not beyond the bounds of practicality to keep a handle on whatever UID was assigned to the recurring payment in the first place, then send the merchant "by the way this subscription UID requested user cancellation".
When I was working on the Fluid Framework, now basically Microsoft's Copilot Pages, we built a URI Schema to let in-app widgets specify the code that would let users interact with the underlying data.
Example: you open the app and load a specific document. Simplified, but this loads a "boot loader" and connects to the data feed of the document. The boot loader reads the first few operations which contains the widget/app code to load all the UX of the application. Examples of widgets would be a whiteboard, a text editor, a table widget, an identity card, a latex widget, etc.
Widgets could be posted outside of the document because any loader that could read the URI could parse it and understand the app code to load and data feed to connect to.
I'm still somewhat infatuated with the design and I'd like to see it much more widely adopted. Security issues were, of course, a major issue.
I love this project! The UI feels so delightful and well thought out. I guess I found another weekend (multi-week?) activity.
If you're looking for hackathon projects, the E-ink ecosystem is well developed enough that they're pretty easy to program against and Claude/the AIs can pick up the API surface. Plus, people generally don't know what they're looking at -- you have to say "kindle-style screen" -- but people (me? but also guests) do seem to prefer having a e-ink screen in the living room over a backlit display because it's so much less intrusive.
FWIW, E-ink [0] AND pomdoros [1] are each a whole thing of mine.
This is a good point. Seems like a likely candidate for an S curve in tech development. i.e. next 15 years of VR are improvements to camera, display, and tracking technology. Following 15 years are brain implants.
Not really, better to leave the AI stuff to the AI people rather than PL people. When you don't, you get gimmick libraries like this rather than a solution that fits into the ecosystem
These folks have no pedigree when it comes to LLMs or AI, so no it does not lend credibility
The natural state of a home is tidy. It was probably empty when the current resident moved in. The natural state of a website is fast. A tiny website can be delivered in one packet.
The home only becomes messy through action. Not intention, but action. Someone has to dirty a dish for there to be dirty dishes. And it's not like you can avoid these activities, that's what a home is for.
It requires a countering action to put things back as they were. So it's action on both sides. Action to make things messy, action to keep things tidy. It's the second action we admire in the tidy home, the fast website.
Even just an eye-test shows it's much faster than that for me.
Pagespeed shows .6 for desktop, but locally I'm seeing frames loaded under 350ms. I would have guessed much faster, but I guess the devtools don't lie.
While this does look like a clone of Notion and I'm frustrated this took SIX (!!) years to ship, I'm unbelievably proud to see this out in public. I was working on this in November of 2017, when we demoed collaborative canvases built with what's now the Fluid Framework to Satya. In fact, I turned down an early job with LimeBike after Steve Lucco let me demo a collaborative YouTube player to to BillG.
A huge congratulations to the team and amazing work on the product. I'm excited to see what comes next.
A few thoughts...
1. The Autonomous Agent/AI stuff has been deep in the Loop/Fluid Framework/Project Prague DNA since the beginning. The 2019 demos to the exec team included "Bindy" (Clippy's smarter sister), which was an intelligent agent that could live translate, spell check, insert content, and more. This demo [1] from Build 2019 includes some of that sauce with the live translate demo (and me back stage operating part of the Teams integration)
2. A huge part of the technical problems with Loop was building a secure launcher like OLE, that worked across Office on Web and Native. In fact, it seems like the M365 AI CoPilot is built on the same technology, which would make sense as you need a way to securely add another collaborator (the AI) and additional cross-plat & cross-app logic.
3. Working on cross app components like Loop and with CRDTs/OT really gets the imagination going. Especially because we were (at the time) very excited about 3rd party components like Asana, SalesForce, or Grammarly. Ideally these could be combined gracefully a la Semantic Web. It'd be so powerful to allow users to modify web pages, combine data sources, and generally own their own environment so they can design their own tools.
Geoffrey Litt recently summarized how AI could unlock this future [2]. I also spent time in crypto with the hope it could unlock this future (by incentivizing people to adopt shared protocols). Loop & Microsoft could also allow centralize enough developer mindshare to unlock part of this vision. (Perhaps more effectively than Code Packs?)
It's really cool that you got to work on this from the early inception. I've had my eye on this since it was hinted at many Ingnites ago.
I've never seen an app that can do live collaboration on a document as seamlessly as Loop. Between my phone, laptop and computer, the changes are seemingly instantaneous and that has to be a major accomplishment.
Asides from the web app being a Notion clone, the actual loop components are the most interesting user-facing tool I've seen Microsoft release in a very long time. I've been piloting Loop by myself for over a year and have been introducing it to my team over the past few months.
It'll be interesting to see how this develops over the next few years. I'm really interested in how 3rd party developers can leverage it.
Could you elaborate on how you can use CRDTs/OT for cross app components? It sounds intriguing but its unclear how they help vs a common api like activity pub?
All state including the app logic, UI, and app state of the component was shared/stored/synced via Fluid (I believe now Azure Fluid Relay.)
This simplified integration because each app only need to include a simple boot loader that could connect to the appropriate endpoint and then load every part of the component.
When I was working on this problem with Fluid Framework, we did a few interesting experiments with "owned objects" and centralized ACL objects. I believe the team primarily implemented centralized ACL because that implementation works for many enterprise use cases.
With a centralized schema provider, you run a connected node on a trusted server and reject changes that are out of schema or should not be accessed by a user.
An owned object is an object where a user (or user group that votes via quorum) that owns the object can veto changes to the object. The changes are temporarily applied until accepted by the owners. I haven't dug deep enough into this BFT implementation to know how our model would map to this model.
