my post here in that proposal was meant to funnel the conversation into this one, since they are very closely related (at least for implementation)
I also didn’t notice that you’re hesitant about the
External Linkingproposal.
Not hesitant, I’m generally for it. Just trying to work out the finer details for it. I think the spec supporting external linking in some way is very useful.
- Implementing extra POST endpoint & making extra network call to implement external link feels a bit redundant to me
why would there be an extra POST endpoint?
Mostly agree, however there still might be cases when “external links” useful in any GET metadata, including the initial one. For instance developers might need to have external link to the text document that doesn’t fit the blink description, e.g. governance proposal text or ToS. So, imo what you are describing sounds like a common sense and best practice to me, but it should not be a strong constraint in specification.
I think a url like this for a governance proposal doc could and should be linked in the description (with the blink client making it clickable), not as a primary action button with the rest of the actions. Unless it is a terminal/completed action of some sort.
Having an “action button” that is an external link that fits into the form ui feels wrong and out of place to me. It takes the user away from the blink vice interacting directly with it.
The only time it feels right is for completed states: instead of a generic “completed button” the blink would render an “external link” in place of the completed button.