sambroner

sambroner.com

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?)

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.

[0] https://sambroner.com/posts/raspberry-pi-train

[1] https://sambroner.com/posts/personal-analytics-2024

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.

I’m pretty sure Anders, Steve Lucco, and Daniel Rosenwasser worked on this. So inventors + current lead PM of typescript.

Should lend some credibility to the project.

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.

Really impressive stuff. Seems to have slowed down slightly now that it's on the front page, but blazing fast when I first opened it.

I have really enjoyed learning from teachers and found "teachers" for fitness, language, and writing.

Has anyone found a teacher for something non-traditional or particularly interesting?

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.

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?)

[1] https://www.youtube.com/watch?v=RMzXmkrlFNg

[2] https://twitter.com/geoffreylitt/status/1637592619269214209

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.

Congratulations to Bruce & Team! Always exciting to see a classmate building cool stuff.

Itd be hard for your computer to have the accuracy to detect it!

How would your approach be similar to or different than Edge DB [1]? Sounds like much more orchestration around the DB layer?

[1] https://www.edgedb.com/blog/building-a-production-database-i...

The Block Protocol is building on a pretty large history of similar ideas, but none have really succeeded. Joel's interest in this project is some cause for hope as is the embrace of existing standards like react, webcomponents, and HTML.

Historically, OpenDoc is pretty relevant. So is OLE. More recently Notion, Coda, Microsoft Loop [1], Anytype.io, etc lean on the same concepts to allow you to break documents into independent & reassemble-able components. There hasn't been a large ecosystem here, although the componentized approach has more traction now as we move away from skeuomorphism.

On the data side, Solid is the most relevant. The models are often the same, users give applications very granular data permissions and progressively authorize data access as required for additional functionality. Developers seem to dislike the model... You don't really know what you're going to be rendering and key features are not really used.

From a pure schema perspective, you have schema.org. It's a pretty comprehensive attempt to catalog structured data for most use cases. It's nice that this project can kinda build on the semantic web, but most people ignore it! That being said, adoption would go a long way towards interoperability between OSS projects.

I'd like to live in a world where everything works together? But I'm not so hopeful at this point because the ecosystem has very weird economics. Ultimately the "Block Developer" needs to be compensated, but the host is the one getting the SaaS or advertising payment. Obviously simple components can be free, but very complex ones may need micropayments, licensing fees, etc.

[1] I helped start Fluid Framework, which is the underlying tech for Microsoft Loop. These are just my opinions and I no longer work for Microsoft.

Wow... this is so validating. I worked on a project I called "Buzz Me Up Scotty" (Or something like that) to do a very similar thing. Just glad someone proved the vision.

Super interesting, I added this (albeit way less pretty) to my personal site and generally got poor reviews. That being said, I'm really enthusiastic about the idea.

Example here: https://blog-545pd1vjp-sambroner.vercel.app/

It's hard to tell from Wikipedia what the 6th-grade reading level is and how its measured. Google points me to Flesch Reading Ease. Not a very precise formula...

If I remember correctly, the NYTimes is written for the 8th-grade level. Similarly, many hospitals/healthcare facilities don't allow writing above the 8th-grade level. So, expressive, detailed, and stylized writing are all easily possible at the 8th-grade level. In fact, I probably write at the 8th-grade level, albeit less clearly.

What's the gap between an 8th grade reader and a 6th grade reader?

Fluidframework.com

It appears I am younger than you (late 20's), but this is my experience. I spent 11 months with extremely challenging back pain and sciatica that started the day after snowboarding with lower back tightness. Luckily I had a doctor that encouraged me to wait a year (a year!) on surgery and the injury resolved 3 weeks before the surgery date.

Had I been less patient, I would have been on my 8th doctor/experiment/magic cure and that would have received all the credit.

Golf & Baseball - very challenging.

Running - Not a problem, which surprised me. I ran the NYC marathon 3 weeks ago and felt better than ever. BUT I can feel a definitive reduction in lower back strength, so I've started spending more time on core exercise.

Familiar athletic movements - Totally fine. Basketball, throwing a football, etc all seem to be fine as long as I keep my body under control.

Awkward athletic movements - Wrestling, new sports... basically anything awkward that requires twisting is bad. Seems obvious when written like this, but many sports can surprisingly fit the bill (Soccer, Volley ball serves, bowling, archery, etc)

Sitting and Sleeping - Every once in a while my SO and I sit down at a restaurant and I have to bail out. There are some chairs that just do not work with my back and trigger sciatica in 10-15 minutes. Very confusing, but luckily she's quite forgiving.

Would be really neat to put Drawpile on the Fluid Framework. You could easily map Drawpile's ordered operations into distributed data structures. I did a similar thing a few months ago with QuillJS's operations and it worked great!

The main advantage of that integration would be a ready made Azure service + future integration with Microsoft Office.

(I used to work on the Fluid Framework)

I'm really glad to see an article like this. I've worked in the space for a while (Fluid Framework) and there's a growing number of libraries addressing realtime collab. One of the key things that many folks miss is that building a collaborative app with real time coauthoring is tricky. Setting up a websocket and hoping for the best won't work.

The libraries are also not functionally equivalent. Some use OT, some use CRDTs, some persist state, some are basically websocket wrappers, fairly different perf guarantees in both memory & latency etc. The very different capabilities make it complicated to evaluate all the tools at once.

Obviously I'm partial the Fluid Framework, but not many realtime coauthoring libraries have made it as easy to get started as Replicache. Kudos to them!

A few solutions with notes...

  - Fluid Framework - My old work... service announced at Microsoft Build '21 and will be available on Azure
  - yJS - CRDTs. Great integration with many open source projects (no service)
  - Automerge - CRDTs. Started by Martin Kleppman, used by many at Ink & Switch (no service)
  - Replicache - Seen here, founder has done a great job with previous dev tools (service integration)
  - Codox.io - Written by Chengzheng Sun, who is super impressive and wrote one of my fav CRDT/OT papers
  - Chronofold - CRDTs. Oriented towards versioned text. I'm mostly unfamiliar
  - Convergence.io - Looks good, but I haven't dug in
  - Liveblocks.io - Seems to focus on live interactions without storing state
  - derbyjs - Somewhat defunct. Cool, early effort.
  - ShareJS/ShareDB - Somewhat defunct, but the code and thinking is very readable/understandable and there are good OSS integrations
  - Firebase - Not the typical model people think of for RTC, but frequently used nonetheless

That’s… way closer to consumer than I expected

Very similar to Solid! Worth checking out. It’s a Tim Berners-Lee project

I remember seeing this in person when walking around the highline around this time. I was with my SO and we thought it was cute, hipster-y, and fun.

What's interesting to me is that we had some of the same sentiments that were expressed so negatively on reddit, but in a very positive light? Crazy how the anonymity and lack of context can easily influence folks to be so negative.

Seriously... there's nature vs nurture, but the nature of this dog is clearly to herd sheep.

For me, this was related to an adblocker

Fluid Framework (a project I contribute to/work on through Microsoft) supports this via token in our default service implementation, but we don't have integration with an ACL DB.

YJS (and Kevin Jahns!) is fantastic, although I'm not sure they're interested in addressing all of these problems. In so far YJS has been very focused on replicating state from one place to another.

And the parent comment may be making light of some of the big issues in the space. You need to be generic, but also performant and simple compared to the competition.

Real time text editing is not trivial although there's solid prior art now. Even undo management is a whole problem space (what should a cross user undo look like if there have been dependent changes).