SUGGESTION: Contacting the instance's maintainer(s)

[TheEvilSkeleton]

This is derived from searx/searx#1972. I personally think that there should be a way to contact the maintainer(s) of a public instance (email for example). It is harder to trust this awesome service if there is no way to contact the maintainer(s).

My suggestion for this change is to tell the maintainer(s) to provide an email address at a minimum.

EDIT: I think I may have applied the labels wrong

[dalf]

If you look at the commit messages, for each modification there is a reference to the github issue and the github profile:

$ git log --format=%B -n 1  $(git blame searxinstances/instances.yml | grep '$URL' | cut -f1 -d\  )

So at least you can get the github profile for the instances registered since searx-instances exists.

Related to https://github.com/dalf/searx-stats2/issues/7

[TheEvilSkeleton]

that's pretty cool and i'm glad that there is a way to see their GitHub page, but it should still be more obvious and still have an easy way to contact the maintainer(s)

[TheEvilSkeleton]

@dalf any update?

[unixfox]

I think adding the email address at the bottom of every Searx instance page would be the better idea. The maintainer would just have to set its email address in the settings.yml file.

[TheEvilSkeleton]

I like that idea

[dasj19]

Public emails is against good privacy... How about a contact form.... it could be made under /contact ... This way we as maintainers of the instance avoid spam and email harversting.

[return42]

Alternative to eMails: You can set Makefile environment ..

GIT_URL Changes this, to point to your searx fork.
GIT_BRANCH Changes this, to point to your searx branch.
SEARX_URL Changes this, to point to your searx instance.
DOCS_URL If you host your own (brand) documentation, change this URL.

These values are also used in the templates and are rendered into the about page / e.g. see section "Where are the docs & code of this instance?" in my instance's about page ..

See the https://return42.github.io/searx and https://github.com/return42/searx

[return42]

The brand is exported to the config URL e.g. https://darmarit.org/searx/config

{"brand":{
  "DOCS_URL":"https://return42.github.io/searx",
  "GIT_URL":"https://github.com/return42/searx"},
}

If we need more fields exported / e.g. a admin e-mail we can add them.

Is this an acceptable solution for this issue?

[unixfox]

Public emails is against good privacy... How about a contact form.... it could be made under /contact ... This way we as maintainers of the instance avoid spam and email harversting.

Why emails are against good privacy? You can create a separate anonymous email just for the questions about your Searx instance.
Emails are the more universal way for contacting a person.
Bots understand contact forms, this won't help against spam and I don't think the maintainers of Searx would want to add a CAPTCHA to the contact form.

[asciimoo]

It is harder to trust this awesome service if there is no way to contact the maintainer(s).

I'm not saying that this feature isn't useful, but the point of searx is that you don't have to trust in any of the instances, you can host your own. I don't think that a contact form or an email address would increase the trust of a service provided by an unknown person/organization.

[TheEvilSkeleton]

I don't think that a contact form or an email address would increase the trust of a service provided by an unknown person/organization.

I might have to disagree. I personally find that providing a contact form or email address would increase the trust as it will make it easier to contact them if you have any questions, found an errored search engine, etc. And providing one of those won't make the service "provided by an unknown person/organization", since you will have an idea of who they are. What does make it unknown is not having a way of contacting them, thus making themselves completely anonymous. That's just my opinion though.

[asciimoo]

Providing contact data doesn't mean anything. They can still use logging or do something malicious, whatever they say. Also, providing contact data doesn't imply that you can contact with them, neither what they say is true. I'd recommend you to not trust in service providers you don't know even if they have contact info.

[TheEvilSkeleton]

You got a point there

[unixfox]

@return42 why closing the issue?

[return42]

Sorry, thought the issue was answered: We render and export GIT_URL (origin of the instance) and Providing contact data doesn't mean anything. was accepted in dalf/searx-instances#45 (comment)

If this is not the answer to "Contacting the instance's maintainer(s)" we can reopen the issue / I reopen for further discussions ..

[unixfox]

We render and export GIT_URL (origin of the instance)

That's not the easiest way to contact a maintainer from an instance. Having to know a specific hidden URL in order to contact the maintainer is not user-friendly. Moreover, the GIT_URL is often just the official searx repository.

Providing contact data doesn't mean anything. was accepted in #45 (comment)

Was it really? I didn't feel that it was. I think @TheEvilSkeleton was just saying that asciimoo got a valid point against the ability to contact a maintainer, not that the issue is solved.

Maybe @TheEvilSkeleton you could confirm if the issue is solved or not.

[TheEvilSkeleton]

Was it really? I didn't feel that it was. I think @TheEvilSkeleton was just saying that asciimoo got a valid point against the ability to contact a maintainer, not that the issue is solved.

Correct

Maybe @TheEvilSkeleton you could confirm if the issue is solved or not.

I personally think that there should still be an easy (and obvious) way to contact maintainers.

[return42]

I personally think that there should still be an easy (and obvious) way to contact maintainers.

Sorry for closing / does anyone have suggestions?

[TheEvilSkeleton]

I personally think that there should still be an easy (and obvious) way to contact maintainers.

Sorry for closing / does anyone have suggestions?

Not entirely sure, but we could do something like this, where the contact will be located in https://searx.me/ as well as the bottom of the Searx instance, in which the maintainers can add a name (or) email, etc. that we can easily contact them. (Pardon me for my image editing skills)

Or something completely different. That's my suggestion.

[dalf]

Currently:

• There is one contact for sure: the one who asks to add the instance (using a github issue).
• This is contact declares to be the owner of the instance.

So I suggest to add a contact field in instances.yml.
For example:

https://searx.be:
  contact: "github:unixfox"

The github:... syntax gives space for an URI (email: , https:, whatever)

The update script can add this automatically.

Then the searx.space website can show this information (information that is already here).

[unixfox]

I think it's better to prioritize the ability to include a contact info into Searx itself because this information could be easily accessible at the bottom of the page and will exist as long as the instance exist.

I know searx.space won't disappear anytime soon but I think this kind of contact information should be tied at first on the Searx instance itself and not only centralized in one place that store the contact info of all the existing public instances.

[return42]

I think this issue can be closed since searx/searx#2391 is merged.

See searx/searx#2391 (comment) / the next we have to think about is searx/searx#2394

@dalf about searx/searx#2394 I have to think twice, I hope I have time to do this at the weekend .. or later.

[dalf]

I was reading this thread, actually there is one missing thing: https://github.com/searx/searx-instances/issues/45#issuecomment-659651297

To do that, /config API endpoint should return the CONTACT_URL : https://github.com/searx/searx/blob/14c7cc0e118f1d0873b32b34793cdec2c5c9c13e/searx/webapp.py#L1068-L1071

Then searx-stats2 can be fetch this information.

[return42]

To do that, /config API endpoint should return the CONTACT_URL

FYI / implemented in PR searx/searx#2408, see commit: https://github.com/return42/searx/commit/038755907295cb48c7deb04dec2b824e4350ee88