channels: custom extension, configuration and post types #4109
Conversation
packages/shared/src/urbit/channel.ts
Outdated
| interface MessageInput { | ||
| type: string; | ||
| postType: string; | ||
| configuration: Record<string, string>; |
There was a problem hiding this comment.
what do you see in configuration? my guess is like – for a button input, what does the button "say" (in this specific channel). if so, I vote we skip this for now – we can do a lot without it, and I think I want to push to make these hoon snippets as well. (unless these string values are actually snippets, hm?)
There was a problem hiding this comment.
right yeah, what would the hoon snippets do here?
There was a problem hiding this comment.
example: button input, snippet calls out to an LLM API, which gives back a fortune cookie response, which is used as the post body
There was a problem hiding this comment.
another one: audio message, hoon applies a user-defined audio effect over the wavetable
There was a problem hiding this comment.
(tbc, i think this means client-side hoon execution to have a decent UX...)
There was a problem hiding this comment.
ftr, I changed my mind on this – I still think that Hoon snippets would be great here, but user configuration through parameters seems pretty important.
(Is there any chance that JSON values look enough like Hoon expressions? like, if we accept values like 3 and 'blue', could we change in the future to say "those were all actually simple Hoon expressions that didn't have any operators")
packages/shared/src/urbit/channel.ts
Outdated
| version: 1; | ||
| messageInputs: MessageInput[]; | ||
| defaultContentRenderers?: ContentRenderer[]; | ||
| defaultPostCollectionRenderer?: string; |
There was a problem hiding this comment.
this is my fault, but I think we should probably drop the default from defaultPostCollectionRenderer, as I don't see a way to have multiple collection renderers – do you? (the only thing that comes to mind is for nested timelines like replies, reactions, etc)
There was a problem hiding this comment.
yeah I don't think we'll have multiple
packages/shared/src/urbit/channel.ts
Outdated
|
|
||
| interface ChannelMetadataSchemaV1 { | ||
| version: 1; | ||
| messageInputs: MessageInput[]; |
There was a problem hiding this comment.
thinking out loud: considering array vs dictionary (mapping ID -> MessageInput) here – array is nice because we'll probably need to order these inputs in the UI somehow, and it'd be good to give control of that to the configuring user.
if we did a dictionary keyed on postType, we could enforce no duplicate postType values
There was a problem hiding this comment.
I don't have a strong opinion here because I don't know what the "multiple inputs" UX is going to be. I guess the no-duplicates enforcement isn't that important because we can just do a runtime check.
packages/shared/src/urbit/channel.ts
Outdated
| interface ChannelMetadataSchemaV1 { | ||
| version: 1; | ||
| messageInputs: MessageInput[]; | ||
| defaultContentRenderers?: ContentRenderer[]; |
There was a problem hiding this comment.
I think this would be better as a map of post-filter -> renderer; i.e. change ContentRenderer to simply { using: string } (or { rendererId: string } – sorry for waffling), and change this to defaultContentRenderers?: { [match: string]: ContentRenderer }. this enforces no duplicate post-filters, and makes it easier for someone to walk through the logic of "which renderer will this use" in their head.
There was a problem hiding this comment.
not a strong opinion though
packages/shared/src/urbit/channel.ts
Outdated
| rendererOverride?: string; | ||
| } | ||
|
|
||
| interface MessageInput { |
There was a problem hiding this comment.
my fault – can we change this to PostInput to be consistent? (also at ChannelMetadataSchemaV1#messageInputs)
| version: number; | ||
| name: string; | ||
| src: string; | ||
| compiled: boolean; |
There was a problem hiding this comment.
what does this mean?
There was a problem hiding this comment.
I was thinking we might need some indicator of whether this source code actually compiles or not so we could surface an error that something is wrong with your code.
There was a problem hiding this comment.
seems useful - i read this as "is this code precompiled" - maybe "valid" would be more intuitive?
|
|
||
| interface Hook { | ||
| version: number; | ||
| name: string; |
There was a problem hiding this comment.
nit: it sounds like name needs to be unique – as a non-urbit user, name feels like "display name" instead of a machine id. id or key is more communicative of the required uniqueness
There was a problem hiding this comment.
yeah this is good feedback will change
| type ChannelMetadataSchema = ChannelMetadataSchemaV1; | ||
|
|
||
| interface Hook { | ||
| version: number; |
There was a problem hiding this comment.
nit: why use a version number instead of a created timestamp? seems like potentially one less thing to keep track of
There was a problem hiding this comment.
I would think that you'd want to know which iteration of this particular hook is running
| } | ||
|
|
||
| interface Hooks { | ||
| allowed: Hook[]; |
There was a problem hiding this comment.
nit: validate matches the "first person present verb" form better, and avoids ambiguity of "these are the hooks that are allowed"
| export type KindData = KindDataDiary | KindDataChat | KindDataHeap; | ||
| export type Kind = 'heap' | 'diary' | 'chat'; | ||
| export type KindDataCustom = { | ||
| custom: string; |
There was a problem hiding this comment.
nit: in an extreme of the custom channels world, everything will end up with kind custom – aesthetically, I wonder if there's another term that we could use to support that. ("user"?)
There was a problem hiding this comment.
I think at that point we'd just change our API so that kind-data goes away and we just have a post-type field or w/e.
PR Checklist