# Collect Tryton references

**URL:** https://discuss.tryton.org/t/collect-tryton-references/2242
**Category:** Ideas
**Created:** [January 27, 2020, 11:37am UTC](https://discuss.tryton.org/t/collect-tryton-references/2242 "2020-01-27T11:37:03Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [January 27, 2020, 11:37am UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/1 "2020-01-27T11:37:03Z")

</div>

At B2CK, we have a frequent request from leads to give references of Tryton in the same field.  
So we think it will be great if the Foundation could collect such information and share it (I think it fit with the promotion mission).  
I think we could add a cron task in standard trytond. This task will be activated as opt-in using the configuration wizard. The task will send to the Foundation server periodically (once per month) this information:

- Name (required)
- Contact email (required) + publish option
- Country (optional)
- Description (optional)
- Version (optional)
- List of activated modules (optional)
- Number of users (optional)

The Foundation server will verify the email by sending a verification URL (like web\_user module).  
Once validated the information will be published on [www.tryton.org](http://www.tryton.org) (with search toolbar). If the data are not updated after a period (e.g. 6 months), the record will be deactivated.  
In order to identify the installation/database, the task will generate a unique identifier (UUID4). The Foundation server will compare it with the stored hash to allow the update.  
All communication will be done with SSL. And the task should not interfere with the normal usage of Tryton.

And of course we will respect of [Privacy - Tryton Discussion](https://discuss.tryton.org/privacy)

---

<div class="post-metadata">

### Author: ![albert](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/albert/32/21_2.png) [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [January 28, 2020, 5:33pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/2 "2020-01-28T17:33:37Z")

</div>

It sounds like a good Idea to me. However, I would separate the list of activated modules from the other information.

I would create one UUID for the contact information and another UUID for the list of activated modules so we guarantee that the list of modules is 100% anonymous. This would encourage people to publish the list of modules they have installed without forcing them to provide their company’s name. This information could be important for making certain decisions for Tryton.

Debian, for example, has the popularity contest: [https://popcon.debian.org/](https://popcon.debian.org/)

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [January 28, 2020, 5:50pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/3 "2020-01-28T17:50:47Z")

</div>

I do not see the point. If we want to collect only modules, we will need any way an email to validate.  
The only extra requirement is the name which can be anything people wants. So I do not see any benefit to split the collection.

---

<div class="post-metadata">

### Author: ![albert](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/albert/32/21_2.png) [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [January 28, 2020, 6:13pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/4 "2020-01-28T18:13:04Z")

</div>

> [@ced](#):
>
> The only extra requirement is the name which can be anything people wants

If the list is going to be published, we’d better not publish invalid names.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [January 28, 2020, 6:14pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/5 "2020-01-28T18:14:35Z")

</div>

Please define what is an invalid name? People are free to name there setup as they want.

---

<div class="post-metadata">

### Author: ![albert](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/albert/32/21_2.png) [@albert](https://discuss.tryton.org/u/albert)
#### Post date: [January 28, 2020, 6:32pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/6 "2020-01-28T18:32:50Z")

</div>

I supposed, that the Name they were sending was the name of the company but I see you expect something else. Then if the company name is not published I don’t see the point from a marketing point of view…

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [January 28, 2020, 8:26pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/7 "2020-01-28T20:26:03Z")

</div>

People will be what ever they want to name their instance. The main goal is that someone contacting them about the reference will be able to able to talk the right one thanks to the name.

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [January 28, 2020, 9:13pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/8 "2020-01-28T21:13:08Z")

</div>

> [@ced](#):
>
> People will be what ever they want to name their instance.

Then we should probably name them “Instance name” so it’s clear that we are refering to it.

---

<div class="post-metadata">

### Author: ![pokoli](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/pokoli/32/22_2.png) [@pokoli](https://discuss.tryton.org/u/pokoli)
#### Post date: [January 28, 2020, 9:25pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/9 "2020-01-28T21:25:59Z")

</div>

> [@ced](#):
>
> Once validated the information will be published on [www.tryton.org](http://www.tryton.org) (with search toolbar). If the data are not updated after a period (e.g. 6 months), the record will be deactivated.

I think we should allow the user to share it’s data anymously by not publishing it’s email publicity on the foundation website.

> [@ced](#):
>
> - Version (optional)
> - List of activated modules (optional)
> - Number of users (optional)

I think this should be an option for sharing each of this features which by default we should check the version, and let the user opt-in for the modules and the number of users

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [February 3, 2020, 11:22am UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/10 "2020-02-03T11:22:16Z")

</div>

We could also collect indexes usage statistic for [Make better index (#5757) · Issues · Tryton / Tryton · GitLab](https://bugs.tryton.org/issue5757) but also other database statistics. For now I only see `pg_stat_user_indexes` and `pg_stat_user_tables`.

---

<div class="post-metadata">

### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced)
#### Post date: [May 21, 2020, 9:26pm UTC](https://discuss.tryton.org/t/collect-tryton-references/2242/11 "2020-05-21T21:26:27Z")

</div>

> [@ced](#):
>
> The Foundation server will verify the email by sending a verification URL (like web\_user module).

Another option would be to use a [Proof of work](https://en.wikipedia.org/wiki/Proof_of_work) against the submitted data.  
For example, we could add an incremental counter (could be just a timestamp or the date) and requires a sort of [Hashcash](https://en.wikipedia.org/wiki/Hashcash).  
This will avoid the requirement to validate the email address.
