Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

💬 Discussion | Should we distinguish between clients, servers, and protocols for badges? #1005

Closed
ghost opened this issue Jun 22, 2019 · 4 comments

Comments

@ghost
Copy link

ghost commented Jun 22, 2019

https://github.com/privacytoolsIO/privacytools.io/pull/1004 made me think about if we should have some way to telling the difference between protocol, client, and server wrt. badges.

Matrix the protocol and Synapse the reference server implementation came out of beta recently but if we want to be technically correct the recommendation is for Riot.im specifically and then we should have removed the beta badge back in February and that just seems wrong when the protocol spec and reference server implementation isn't out of beta.

@ghost ghost added the feedback wanted label Jun 22, 2019
@Mikaela Mikaela added ✨ enhancement 🌐 website issue *Technical* issues with the website. 💬 discussion labels Jun 22, 2019
@Atavic
Copy link

Atavic commented Jun 22, 2019

Nice idea, a green badge for servers and a red one for clients will make File Sharing section more clear (with only Firefox Send with a red badge). Instant Messaging section will be improved, dividing green decentralized services from red centralized services.

@jonaharagon
Copy link
Contributor

IMO the tags should represent the full stack of software a tool is using. So because Synapse is the only server-side software for that particular application and was in beta, and because the protocol the client is built on was in beta, the tag should say beta.

I'm not even sure if we should list "beta" at all and stick with "experimental" for tools we have concerns about: #1007

@Mikaela
Copy link
Contributor

Mikaela commented Oct 7, 2019

@dngray Thoughts on this related to #1377 (I still haven't read the most recent changes/comments)?

@dngray
Copy link
Collaborator

dngray commented Oct 7, 2019

I think this one is a duplicate of #1377. I also think badges would be a messy and lazy way to do it. Those are for just 'small notes' or 'warnings'.

@Mikaela Mikaela closed this as completed Oct 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants