Yes, I have described my use case and just gave a follow-up based on your feedback (thanks heaps!).
I intend to use Domain-Driven Design and that combines really well with an Actor Model. Vaugn Vernon presented a lot of information on such an architecture design. But where he advocates to turn domain aggregates into Actors, a better approach imho would be what Alexey Zimarev (who is collaborating with Proto.Actor founder Roger Johansson) proposes, and remove Actor dependency from the Domain layer and have an actor manage a domain aggregate in the Application layer. An advantage is that the actor, after retrieving the aggregate state from storage, can cache the aggregate in actor state for subsequent invocations, during its lifecycle.
Other than actors supervising domain aggregates I would have an actor hierarchy with a Server actor at the root, a Community actor, Federation actor, etc.
But I guess my response here was mostly to observe that for prospects that investigate actor systems for their tech stack, and bumping into Temporal it is not clear to see differences and similarities to the concepts they familiarized themselves with, and are e.g. comparing one-to-one to what the (very popular) Akka framework has to offer. It is not immediately clear what the subtle differences and implications of using Temporal are. Both in terms of characteristics and design patterns. While you can use it to model actor systems, Temporal has a different paradigm and needs to be ‘molded’ into that shape, as it were.
(Note that there’s other terminology that might lead investigators astray, such as Temporal’s event sourcing, which serves Temporal internally but (probably) does not fulfill ES requirements in an application design (with append-only logs in an eventstore, time-travel capabilities, etc.))
Today I found @SergeyBykov’s blog post The Curse of the A-Word that compares to design decisions made in Orleans. Maybe some blog posts like “Temporal and Actor System” or “Actors: Temporal vs. Akka” would be enlightening for prospects checking your product.