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

Closed
opened 2019-06-22 13:15:24 +00:00 by ghost · 4 comments
ghost commented 2019-06-22 13:15:24 +00:00 (Migrated from github.com)

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.

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.
Atavic commented 2019-06-22 20:46:04 +00:00 (Migrated from github.com)

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.

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.

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

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 commented 2019-10-07 13:55:48 +00:00 (Migrated from github.com)

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

@dngray Thoughts on this related to #1377 (*I still haven't read the most recent changes/comments*)?
dngray commented 2019-10-07 14:02:45 +00:00 (Migrated from github.com)

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'.

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'.
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1005
No description provided.