INTG: Public-facing no-auth chat interface backed by an admin-designated space

[cwang]

Is your feature request related to a problem? Please describe.

There're cases where a business would offer external people (partners, customers etc.) access to a certain portion of their data, usually already publicly accessible such as product literature and knowledge base.

This feature would extend the organisational data's use beyond internal applications.

However see the context below for the potential pushback.

Describe the solution you'd like

Just like #14 this can be piggy-backed to #22 or build something quick before the API-support is available.

See RFC for the backend in #57

Describe alternatives you've considered

N/A

Additional context

The pushback for NOT implementing this feature is mainly for the absolute guarantee of data security, as this opens doors for misconfigured private spaces being used as the data source for the public-facing chat interface. Although it'd be a user error, it's Docq that has this feature to allow it to happen. This is the reason to be cautious about this feature.

[janaka]

I feel this feature could be a great selling point / conversation opener that people can relate to. It's a core differentiator, but an answer/defence to secondary needs.

Re: the security risk - worse case a customer could run a second instance just for this if they feel like they need even more layers to prevent leak. But if we get the Space based partitioning right (all the way down and across the stack, like indexes, prompt history storage etc.) and the permissions + audit trail on top 👌🏾 then customers should feel like they need to. I'm assuming the model doesn't "remember" and leak across the Space boundary (this is the bit I don't understand enough yet to have confidence).

[cwang]

This should be embeddable to any website, therefore it's likely to be a JS widget. There're many existing examples of such chatbots.

[janaka]

Would an iframe work for now? depends on the setup of the site we are embedding into I think. For a JS widget we'll need the API etc. which is just more work out the gate before the gate before validating.

[cwang]

I think it's a good idea to put something together without the APIs. May still need some js trickery to get the intercom-like button up and running; iframe is just one of the ways among others.
cc @osala-eng

[osala-eng]

I think it's a good idea to put something together without the APIs. May still need some js trickery to get the intercom-like button up and running; iframe is just one of the ways among others. cc @osala-eng

Noted

[janaka]

I think it's a good idea to put something together without the APIs. May still need some js trickery to get the intercom-like button up and running; iframe is just one of the ways among others. cc @osala-eng
yeah, ease of integration and then one way or another have to have options to handle CORS.

[osala-eng]

@janaka @cwang

For the js widget, should I set it up in this repo or create a separate one just for it

[cwang]

@janaka @cwang

For the js widget, should I set it up in this repo or create a separate one just for it

Maybe a separate repo?

[janaka]

The pushback for NOT implementing this feature is mainly for the absolute guarantee of data security,
A few thoughts to mitigate

• have a specific permission/role for making spaces public.
• a admin kill switch so a broader set of people can quickly disable the space in the event of suspicion that something slipped.
• require two different users, with the above make public perm, to approve turning a space public.
• all or some of this can be when hyper secure more is one so that companies that aren't worried don't need to take the hit on the UX.
• some way down the road we could probably also have some guard rails that warns based on rules.

[cwang]

I'm building another layer between users (authenticated or not) and spaces - I call it engagement.

The idea is that engagement:space is 1:N to start with, as a flexible layer to handle space unions in a persistent form, i.e., can be saved in persistence storage and retrieved back later.

Then it can be assigned to either users or groups internally, as a shortcut if you like; or assigned for public access, more to build customer front applications such as CS chatbots etc. while not tightly coupled with a single space.

[osala-eng]

I'm building another layer between users (authenticated or not) and spaces - I call it engagement.

The idea is that engagement:space is 1:N to start with, as a flexible layer to handle space unions in a persistent form, i.e., can be saved in persistence storage and retrieved back later.

Then it can be assigned to either users or groups internally, as a shortcut if you like; or assigned for public access, more to build customer front applications such as CS chatbots etc. while not tightly coupled with a single space.

Okay, I'll suspend working on thisfor now until you are done with this.

[janaka]

@osala-eng you are no longer blocked on this one right?

[osala-eng]

@osala-eng you are no longer blocked on this one right?

No longer blocked, currently working on it.