Forgefriends software naming

Is there a reason to not use forgefriends everywhere ?

And install redirections wherever possible to avoid broken links.

It would make sense to me that fedeproxy is no longer used in any context. Unless I’m missing something, it would only lead to confusion to keep fedeproxy around. People who will discover forgefriends after the name change do not need to know about fedeproxy.

By the end of the month fedeproxy will have significantly matured and this is very exciting: a good name, a good logo (I love the current logo but I have to admit the new one is better), a good language and a good codebase to build on.

1 Like

A post was split to a new topic: Redefining and positioning the forgefriends project

That makes perfect sense to me, thanks for spelling it out. What about “forgefriends proxy”? I.e. having a technical component name while still carrying the nice name of the larger umbrella?

P.S. You are absolutely correct in that I tend to have a narrow focus and forgefriends should be a home for broader and more diverse visions.

1 Like

The reasons I find “Fedeproxy” better is:

  • More descriptive as a whole.
  • Positioned as Forgefriends Fedeproxy, a project.
  • Fedeproxy on its own is meaningful too, for common stand-alone use (e.g. in chat).
    • Just Proxy would be too generic.

(Btw, I like the capitalization as used here, and it would still sound good through a screenreader I think)

I disagree. I’m convinced nobody infers any meaning from “fedeproxy”. Other than “it contains proxy in the name, therefore it must be a kind of proxy”. I like the use of a generic and well defined name (proxy) that is contextualized by the larger project to which it belongs (i.e. forgefriends).

Not in itself. But it is a name that has meaning in context of the whole Forgefriends initiative. Could also call it “gaia” or “birdflight” project or anything, which would be meaningless to outsiders.

“Proxy” on the other hand is an overloading of a common technical term that can only lead to confusion. There can be many proxies all across the forgefriends codebases or 3rd-party projects. You can no longer quickly type “fedeproxy” in a rushed chat session, but have to specifically type “forgefriends proxy” all the time to avoid such terminology clashes.

1 Like

Note that the name does not NEED to be Forgefed. It could also be ForgeProxy, or something like that. But it does federation too, so forgefed isn’t that wide off the mark, and it already has some history to it.

Yes, but that’s true of other projects as well and not necessarily a problem. One would likely type “forgefriends” and find the list of software published in this context, among which the proxy. Same as go-fed which contains the “activity” project.

I’m easily overloaded with names, that’s probably a reason why I’m reluctant to make up names where there is no compelling reason to do so. Having a good name for a new concept / project such as forgefriends is a compelling reason. But making up names within that context when generic names are unambiguously describing a piece of software seems to be unnecessarily complicating things.

It is a proxy in that it sits between the client and the server and there are many kinds of proxies because the pattern is relevant in various contexts. The term “proxy” is overloaded by definition: it does exist in the abstract but needs to be applied to a concrete case to be fully specified.

I assume you meant s/forgefed/fedeproxy/ ?

Yes, this is another very bad example that I would never have used myself. It is entirely non-descriptive and when I look into the list of repo’s then it tells me nothing, so it is only hoping that a good description is given to it. These kinds of names are flaws of doing good PR and marketing.

There’s an example of a company that has common names for things that are both products and projects / technical components and that is Hashicorp. If you look at the names they chose you see that they don’t have direct clashes with technical terms in their own domain. So names like Vagrant, Terraform, Consul, etc. They also have ‘go-plugin’. Imagined they named that ‘Plugin’… boom, you’d never be able to find it without knowing more of the context it is applicable to.

People that are deeper involved into a project tend to speak the common terminology / slang naturally and in their short forms. With a name like ‘Proxy’ around, they also make toots such as “I just PR’ed [cool stuff] to #proxy. And anyone reading and interested in [cool stuff] would be lost. There’s no googling of it, proxy is max. overloaded term.

If you wanted to follow a similar strategy to Hashicorp and choose a very comprehensive single word, then you might look in the thesaurus of “proxy”, and idk maybe choose: Deputy (in the meaning of: “A person/thing appointed or empowered to act for another”).

Yep, indeed :slight_smile:

1 Like

Btw, do you know about the AP projects bridge, federation, activitystreams and inbox? Recommend checking them out :stuck_out_tongue:

1 Like

I split the discussion related to naming the software created in the context of the forgefriends projects because it deserves a separate discussion.

@aschrijver I took time to reflect on your explanations and it makes senses. It would be fine for the software that came out of go-fed to be named go-fed, if there was just one piece of software. But since it turned out there were more than one… choosing generic names was probably not the best move.

As of today fedeproxy is just one piece of software, named fedeproxy and distributed under that name on PyPi and the forge on which it is developped. This will change to be forgefriends but if there ever is another piece of software, there will be a need to come up with new names to distinguish them. And ForgeProxy would then be a better choice than proxy, you have me convinced :slight_smile:

1 Like

Cool. Idk, maybe at the time it might make sense to do a further breakdown e.g.

  • Forgefriends IssueBridge
  • Forgefriends CodeMerge
1 Like