start-os
start-os copied to clipboard
Start9Labs
[feat]: add Common Title property to service manifest
Prerequisites
- [X] I have searched for existing issues that already suggest this feature, without success.
Describe the Feature Request
In the case that the service being packaged is an alternative implementation of a relatively well known piece of software, the Common Title property would be used to hold the service's most user-understandable name.
e.g. the Title would be Vaultwarden and the Common Title would be BitWarden.
In the EmbassyOS UI and in the Marketplace, the Common Title would override the Title in most visible places whenever it is given a value. In such cases, the Title would instead be displayed as a de-emphasized element (such as a sub-header) beneath the Common Title.
Describe the Use Case
There's occasionally confusion about the difference between BitWarden and VaultWarden, or Synapse and Matrix, etc. End users are usually not aware of the differences between these forks and do not need full awareness to operate them. Transparency is good, so the differences should not be hidden, but they can at least be de-emphasized to make the content of the service more clear.
Describe Preferred Solution
My guess is that the Common Title would best be added as a property in the manifest.yaml, and would need to be displayed anywhere and everywhere that the user can currently see the Title. All interfaces would need to be modified to support a de-emphasized title slot.
Describe Alternatives
Instead, the current Title property could be interpreted as the "common" name of the project from now on, and a new property could be added for the "actual" title. In this case, the actual title would only be shown in the UI when the property was given a value.
Anything else?
It might be helpful to also add a manifest property that is designed to hold a brief disambiguation of the two implementations, and display this text in the UI when hovering the de-emphasized title, or info badge, etc.
I'm curious how useful this will be. I can't currently think of another service (present or future) that would benefit from this feature. That said, it would be optional so it doesn't hurt.
My main concern is actually around misrepresenting the service. While Vaultwarden and Bitwarden are similar enough, varying only in architecture and a few features, other services may differ in more meaningful ways.
Perhaps simply renaming the field and displaying it as such could help? Calling it "similar to" might work, or better yet, "implementation of". That way, we could use it for Synapse too, "an implementation of the Matrix protocol". Or "Vaultwarden - an implementation of the Bitwarden protocol", though not everyone will understand what that means.
This could also just be handled in the service description.
Just some thoughts.
I can imagine something more general for this: differentiation between protocol and application.
Here, the protocol is Bitwarden, the implementation is Vaultwarden. Other cases where we have this: Lightning <-> (LND, CLN, Eclair, Sensei), Bitcoin <-> (Bitcoin Core, BTCD, Knots), Matrix <-> (Synapse, Conduit), Ethereum <-> (geth, parity).
Perhaps it would be sensible to have a list of protocols that a package implements and have those listed somewhere? Server software always abides by at least one protocol of significance, perhaps standardizing how we communicate that is useful.
@ProofOfKeags was just thinking this! Would be awesome for a service to be able to specify a Common Protocol rather than a specific implementation, that way we could easily switch out bitcoin, lightning, matrix implementations, etc
Interesting, in certain cases and under strict enough criteria, instead of depending on another service, services could depend on any service that implements a particular protocol. Protocol dependencies as an OS feature. @dr-bonez
I think there's a fair bit of distance between being able to specify those protocols colloquially and having a system that is modular over protocols. But yes, aspirationally this is what we should be after.
Correct, that would be a major feature, involving the entire stack, all the way to messaging and docs. The MVP of this is just @spencerflagg original suggestion, just swapping out "Common Name" for "Protocol" or "Protocols" and displaying the value in the UI.
Protocol dependencies as an OS feature.
The tricky issue here is who owns the protocol namespace. Who gets to write the protocol declaration/semantics perse and how does the OS maximize the ability of these things to work? With package dependencies, it is clear what the concept of ownership looks like, the package author is the owner. Maybe this isn't an issue and you can rely on people to naturally come to consensus on what the protocol names mean. In many cases protocols are well specified and so you shouldn't run into situations where things don't work.
In our case we would need to abstract out a protocol spec, potentially based on a reference implementation. Bitcoind, for instance, is an RPC interface and a p2p interface, as far as its dependents are concerned. Both interfaces consist of commands and their parameters. I wonder if there's a protocol spec for defining protocol specs that is general enough to define any protocol.
CLN and LND share an interface because RTL created a CLN plugin to translate CLN to match LND's rest interface. So this de facto defines the "lightning node rest" spec. So I wonder if we could also use dependent services as a way to abstract out a protocol spec.
Presumably we'd need to own the spec for many of these interfaces. But I'm thinking the relevant upstream repo maintainers would be interested in taking over spec maintenance.
This seems complicated. But really cool
@Kixunil has some interesting interop RFCs that may be worth looking at here: https://github.com/Kixunil/interop-rfcs
@dr-bonez yeah, that should help with one part of the problem: configuration, it is not a dependency manager (I just use apt for that :)). Sadly I didn't have much time to implement interface files yet but if people are interested in collaboration I'll look harder into scheduling time for that.
I wonder if there's a protocol spec for defining protocol specs that is general enough to define any protocol.
TLA+ is the gold standard here.
Interoperability between protocols is not presently working well enough to support a feature like this.
The original request here was to add a "common title" field, which would display more prominently than the title.
This is replaced by adding keywords to the manifest, allowing users to search for "matrix", eg, and find "synapse".
This still doesn't completely address the original request, but I think it brings us a lot closer.
What do you think @spencerflagg ?
Either way, I like it.
I believe I was originally trying to solve a Telegram Group problem more than a marketplace problem, if you will. There was a lot of "Where's Matrix?" "How is Synapse different from Matrix?" etc in the community and I think that streamlining the way these esoteric concepts are discussed will help the layperseon. But yeah, hard problem.
Since you're going with tags, what if you added some curated layperson buttons at top of the marketplace like "replace whatsapp" and "replace icloud", and those would filter the marketplace list on anything tagged #whatsapp etc. And tie that to the url, a la /marketplace#whatsapp so the link can be shared.
Maybe open a new issue? This one is closed and I'm not sure people will see comments here