streamize

Livekit supports the distributed concept, but the api key is difficult to apply to the distributed concept. Also, it cannot be added during execution.

how about this structure ? this is redis provider example https://github.com/smtm-private/protocol/blob/48cdf798c23661671b2902b651452c0a788e255b/auth/provider.go#L1 https://github.com/smtm-private/livekit-server/blob/7bfa8af62ed645ba8de59fef4772aa2437efdf19/pkg/service/utils.go#L116-L145 this is changed version of wire_gen.go code. createKeyProvider is placed in main.go before https://github.com/smtm-private/livekit-server/blob/7bfa8af62ed645ba8de59fef4772aa2437efdf19/pkg/service/wire_gen.go#L15-L26 user can choice auth_type...

> Btw, I think we could move this entirely to livekit-server. The redis dependency doesn't make a ton of sense for the protocol repo. Does that mean I don't need...

OK, as you said, if the purpose of the protocol repo is to define interfaces, you mean moving FileBasedKeyProvider and RedisBaseKeyProvider to livekit-server ?

- [ ] Paper release (Under Review) - [ ] Code release (After paper release) you can check readme.md file

@chenbinghui1 thank you for answer. I have one more question about support model type. what kind of stable diffusion model used for replaceanything? ( xl or 1.5 )

@ucasligang do you have any plan to implement fastcomposer support the XL? I think move this repo code to support XL... with train again

@ucasligang plan to pull request to this repo?

@ucasligang hello? any update?