Spaces:

neongeckocom

/

NeonLLM

like 0

Running

Adds support for OAuth login via Google
Adds permissions model described in https://github.com/NeonGeckoCom/BrainForge-Documentation/pull/9
Refactors app.py into separate methods
Defines configuration for permissions_override and huggingface_text

Demo available at: https://neondaniel-neonllm.hf.space/

Instead of adding reserved_keys, better to solve this problem by migrating all models to models and update config
We dont have any other places with this config structure so it don't brake any compatibility

This place look strange
What is the purpose of this dublication

client = Client(
            api_url=os.environ.get(config[name]['api_url'],
                                   config[name]['api_url']),
            api_key=os.environ.get(config[name]['api_key'],
                                   config[name]['api_key']),
            personas=model_personas
        )

By using permissions_override per model not per domain we expoce model names in config
Hope it's not a problem

Maybe it worth to migrate development of demo to github and create an action of deploying it to hf (just a thought)
HF PR is much less advanced

This way we also will be able to auto deploy dev branch to private hf demo for testing
And main branch to public hf demo for example

But only in case if such big addiding to hf demo will be frequent

By using permissions_override per model not per domain we expoce model names in config
Hope it's not a problem

Good point; maybe the HF config should be per-endpoint and not per-model.. In either case I think it will be uncommon that we override things there.

Maybe it worth to migrate development of demo to github and create an action of deploying it to hf (just a thought)
HF PR is much less advanced

This way we also will be able to auto deploy dev branch to private hf demo for testing
And main branch to public hf demo for example

But only in case if such big addiding to hf demo will be frequent

Maybe.. I didn't realize HF was so limited in PRs. If we did move to GitHub, then I think it would be easiest to package the demo and in HuggingFace just import it. That way HuggingFace is just static and any development is done in the GitHub repository with some optional automation to restart HF spaces upon changes

This place look strange
What is the purpose of this dublication

client = Client(
            api_url=os.environ.get(config[name]['api_url'],
                                   config[name]['api_url']),
            api_key=os.environ.get(config[name]['api_key'],
                                   config[name]['api_key']),
            personas=model_personas
        )

Slight change from previous behavior; if the configuration value is in envvars, it uses the envvar as it did before. If the config value is not an envvar, it is used directly. I did this so that I could specify a URL in configuration directly (those aren't particularly private and will show up in requests when the user loads/uses the HF demo anyways).

Good point; maybe the HF config should be per-endpoint and not per-model.. In either case I think it will be uncommon that we override things there.

Looking again, that is how this is currently implemented. client is the endpoint name, not model so the override would specify Alpha as a key (for example)

Looking again, that is how this is currently implemented. client is the endpoint name, not model so the override would specify Alpha as a key (for example)

Then it haven't improved situation in comparison with override field in client, instead of separate section
And I was thinking about extention not override

(Sorry for this movements, they are about behaviour, not code, after your comments ready to close this story)

I made some small fixes after more testing on this fork.

If there's nothing else, I believe this is ready to merge (configuration changes should be backwards-compatible so the current demo should not break upon merging).

those aren't particularly private and will show up in requests when the user loads/uses the HF demo anyways

Logs are available only to authors (just info)

Found rendering bug
When you aren't logged in third model is listed as CPU Inference (BrainForge/NucleotidingsLLM@v0.1.2) but internally it is private model

This is because any private model added at the end to match num of models, but they should be added in place
(Or something else, it's strange behaviour)

P.S.
This is because llm_host_names isn't overwritten after update

Approved

Concerned about radio button rendering issue
But fine for now
Will check later, for now it works, and don't expect big changes soon

Just please squash small fix commits

Just a note that merge here appears to squash and merge commits