Is Hoot scope creep? What is Spritely's scope?

Hi! So as far as I understand, Hoot was the next logical step in porting Goblins & friends to the web; I think that could maybe work (and I’m sure the team has put much more thought into it!) 1) but besides Figma I can’t think of any production deployments of extensive amounts of WASM? And that worries me.

Running a quick search I don’t see any hits for “roadmap” and I’m not aware of like, a specific set usecase that Spritely is being built against. 2) How is the project bounded? “Re-Architecting Communication on the Internet” is incredibly vague.

And like, I do like reading @cwebber’s writeups quite a lot and usually find myself nodding along, but if Spritely is trying to be a technically exhaustive project (“we will build the whole stack of our dreams, as far as we think is doable given constraints”) then I think it also needs to be exhaustive about its messaging. Where can I see the project direction laid out? I’m thinking meeting minutes and definitive statements about goals. My hope is that Spritely does have opinions about what things should be easy to build with it, given Randall and Christine’s backgrounds.

Lastly, 3) I am curious about how funding ties into that planning, given that Hoot explicitly started because of a MetaMask grant, and MetaMask’s parent company is certainly not aligned with Spritely.

3 Likes

I’ve been under the impression that the subtext behind Hoot is “Goblins on the Web”, but given 1) Agoric and 2) the old roadmap, I’m also not convinced that it’s supposed to exist

The closest thing I can recall to a roadmap is the old homepage at https://spritelyproject.org/, which lists out the components that will presumably be built by the organization.

Obv thigns have changed since; Questie is implemented in the Goblins codebase, and there was no mention of Agency. (seriously, what is that supposed to be? (goblins actor-lib)++? an engine for future Fantasary?)

2 Likes

I am following the WebAssembly trend for a while now, from the perspective of “What kind of bet is one making when going with Wasm as early adopter?”. My impression now is that there’s a real there there. Developments in the field are going rapidly, and of course many people are critical (“Meh. Another CORBA? JVM done right? Not gonna happen”). WebAssembly has a long way to go, and one should realize the risk of early bird entry. Much is bleeding edge. There’s also undoubtedly a hype cycle coming where Wasm is over-pitched for things where it shouldn’t be used. This cycle is already picking up steam, and there are frequent discussions on HN on wasm-related works.

I put together a kind of a survey with random bits and nuggets that are inspiring for projects I am interested to evolve. You can see that here:

For me the browser-based applications aren’t the most interesting, but it is use server-side based on WASI/Component Model.

I do agree with what you are saying. I once wrote a long post on this forum that TL;DR’ed into that successful technology adoption requires much more than doing deep technical work. I think its likely that people at Spritely are highly aware of that, and I assume that the rather opaque operational activities are a deliberate choice. It may be a good one too, idk.

What I’ve seen during my years in IT (from 1997 onwards) is that the road to adoption is highest risk, and very often underestimated. In my post I mention Solid project, but in feedback I gave at the time I predicted DAT project to fail as the team was too absorbed in tech. Yet right now, Paul Frazee, working on greenfield tech in Bluesky and alongside business-savvy folks I deem to have much better chances of success with their ATProto specification (for better or worse… I’m a grassroots fedi, FOSS afficionado, and remains to be seen how Bluesky fits in that picture). They roll all that out in a very controlled manner.

So summarizing my thoughts:

  • I understand that working in a close group may have its advantages.
  • But it may be smart to community that better, for all those folks watching and waiting.
  • Right now Spritely does not give opportunities for a healthy community & ecosystem to be established around it. But it may be too early for that phase, and it requires lotsa effort and organization.

While I’m neutral wrt the source of funding (trusting the people involved with Spritely and their principles) I’ve seen quite a few people raising eyebrows. Funding is the achilles heel in FOSS-based R&I, and good funding opportunities are hard to come by. And I guess it is fair ask to explain how that impacts the project and roadmap. Though maybe that too is for a phase where community-building starts.

I should note here that Solid project with VC-funded Inrupt is struggling with their approach to funding and commercial pathway to adoption. Technology adoption imho best works bottom-up by winning the hearts of developers. Solid until now neglected community in favor of deep tech formal working groups and closed business meetings between partners and prospective customers.

4 Likes

Hello! There’s a lot of points raised here, and I want to address them as best I can.

To address @ckie’s main question, Hoot isn’t scope creep: we needed a way to get Spritely’s applications to the everyday user. It’s been in our plans since early on to have an answer to getting Spritely to desktop, mobile, and browser users. We knew we had to work on a solution, but we actually expected that the start on that work would be on 1-2 years from when Hoot initially got funded. So what you’ve seen through the funding aspect is that when we talked to the folks at Metamask about funding possibilities, we laid out our roadmap, and Hoot was what they were excited to fund, so it got accelerated. (This funding is not work-for-hire and is not tied to any blockchain technology.) But this is really exciting and in retrospect a big relief, because it means that one of the biggest looming questions is being addressed early: we have a path to reach a much wider audience, and that path is the browser!

That said, I understand how it’s confusing. As @parnikkapore points out, the older https://spritelyproject.org/ website may have been confusing for many users, but did have a roadmap. However that website dated from when Spritely was primary a solo project by me. We have a new roadmap which has been established internally since the Spritely Institute has been founded in January 2022. Making this roadmap more public and visible is in the works; we are will be including it in our website revamp in 2024.

Regarding the question of “what is the Agency supposed to be”? The Agency is a name for the peer-to-peer user agent that Spritely will be giving to users. “Client” doesn’t make as much sense because our user-facing application won’t be client-server. The term Agency is a term from the Electric Communities name for the same thing.

Now to rewind, back to the why Hoot is actually a great fit for Spritely’s roadmap: when it came to delivering our Agency to users, we had viewed a lot of different approaches internally: having different implementations in different languages (that’s a high maintenance burden), having different frontends for different platforms (still a high maintenance burden), or somehow getting our code into the browser. The WebAssembly GC proposal looked like it was going to land at the perfect time… and indeed it has! We are very pleased that nightly builds of major browsers are able to run Hoot-generated code. This cuts a huge amount of work off of Spritely’s plate by doing Hoot up front, at the expense of having the effort done much earlier than expected. That the Metamask folks (who are also big object capability security fans, that’s the other connection) were excited about Hoot as a project and to see Spritely’s tech in the browser in general meant that this was being resolved much, much sooner. We’re all very proud of it and thrilled we got to work on it so early.

I hope that answers your all’s questions!

5 Likes

Yes. The ~2 year wait for transparency is rather appalling, but I could see how a lot of that is wanting to get all your publicly-visible ducks in a row first[1] and having to make do with the funding you can find. Does that sound right?

I’m looking forward to see what shape Spritely takes when there’s a early-bet/late-alpha application & associated protocol out. I’m scared of the following pitfalls:

  • Spritely stays closed off, with a core team that meets in private or read-only meetings; prone to it getting stacked with corporate employees hoping to influence the protocol. This is a slippery slope from the current “we want to stay small while we’re young” and needs to be consciously prevented here.
  • Spritely commercializes, running a “flagship instance” like mastodon.social or matrix.org and developing the spec side-by-side.
    • In Matrix/Element, this means PRs get mysteriously blocked by invisible internal matters and roadmaps aren’t visible until they’re implemented unless you poke employees.
    • Parts of the Matrix spec have been influenced by limited funding runways before.[citation needed]

I hope that makes sense. Thank you for all your explanations and time so far (:

(I think Spritely-the-idea is very cool. I really want to see it survive its birth.)


  1. first impressions seem super important! especially when you have to contend with the network effect. ↩︎

2 Likes

I will be brief in my reply as I need to prepare for meetings and a presentation over the next couple of days, and @frandallfarmer is planning on replying to this thread but is out of the office today. Two things:

  • We have been very heads down on putting the core architecture together but are actively working on increasing our amount of transparency and community involvement; I will let @frandallfarmer say the rest.
  • Having Spritely’s tech be 100% FOSS under a nonprofit (very specifically, since we are US based, 501(c)(3) nonprofit) was a prerequisite for both @frandallfarmer and myself before agreeing to co-found an organization. We are building the future of networked technology, and we believe it is crucial that such work be done putting the public interest first rather than the interest of any specific for-profit institution. We are advancing the intellectual commons, and there is no way to do that in a neutral way with a primary commercial interest I believe.

That’s all for now, I know @frandallfarmer has more to say when he’s back!

3 Likes

We’re 100% FOSS and a publicly funded non-profit.

All of our work is publicly available. Anyone can clone, fork, open issues, or make PRs and we are hoping that many see the benefits of this work and make these contributions.

We are leading collaboration with any and all interested parties on the important interoperability standards that are required for a secure networked capability-powered decentralized world: Please checkout and join the OCapN project: https://ocapn.org/ We have contributors there from several interest groups. Check it out! This critical interoperational protocol work is all in the open and not “closed off” in any way. If you have something constructive to contribute, please join us!

As to Goblins (our capability programming platform), Hoot (intended to allow us to deploy everything everywhere), and the Agency (a universal base p2p client/server) - These are each in various stages of initial development. There is a “minimum viable” configuration that can serve as a common base for parallel development by many different (divergent) parties. We need to get them to a place where they are “good enough to use/critique/improve.” It’s hard work and we can’t wait to get you more involved. This is why we’ve been doing 0.x releases whenever we can, even though it’s super rough, some people are willing to help us shake out and improve the components.

That all said, the big news is we just hired our Open Source Developer Relations Manager (exciting announcement on our blog in the next few days) because that we agree that we have been a bit behind on the community front. We’ve now got the help we need to spend more time communicating our progress and plans, as well as being active in working with integration partners and early-adopters.

Here’s a very crude layer-cake diagram from one of our presentations - I hope it helps. We’ve been focused on the “White/Core Layer” (aka Goblins) and Hoot helps us start on the Agency… There is so much more to do, but much of it will be making use of existing standards and various groups that want to integrate.

But, to be clear - None of our grants have been work-for-hire for anyone. They are all donations. We pitched work that we want to do, asked for donations, and they said “Sure! Here’s some money to help get that important work done!” No strings attached. No Blockchain or AI or Metaverse or any other strings. Don’t get me started about stupid tech bubbles! :slight_smile:

We also applied for an NSF POSE grant [application is still pending] specifically to get money to focus on expanding our open source ecosystem. The new hire is included in that grant proposal, but we felt we couldn’t wait on the grant evaluation period before we hired this person. We took 15 pages in that application to describe our plans for the future - we’ll be compressing that for sharing on the website as soon as we can. :slight_smile:

That plan describes how we want the same thing you do, for parties with genuine interest and stakes in re-decentralizing the social web to be able to fully participate in the design/development/governance process for a common set of protocols, exemplars, patterns, and objects.

So - if you want to help, step right up!

5 Likes

The Agency sounds nifty.

It sounds like it overlaps quite a bit with the endo pet daemon.

Endo Pet Daemon Development Spike · Issue #1614 · endojs/endo
Endo Sync: Pet Dæmon Motives - YouTube

I’m particularly interested to integrate Spritely’s petnames work with some Agoric stuff.
more on that elsewhere, most likely…

1 Like