Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIP for fruit tree and flowers #990

Open
lordazzi opened this issue Jan 15, 2024 · 13 comments
Open

NIP for fruit tree and flowers #990

lordazzi opened this issue Jan 15, 2024 · 13 comments
Assignees

Comments

@lordazzi
Copy link

lordazzi commented Jan 15, 2024

I don't know if this repository is the appropriate place to propose NIPS, if not please direct me. #grownostr

Proposal
Preparation of NIPs for the following needs:

(A) Identify a unique element, an artifact, a specific plant or a specific animal, which may have unique characteristics, such as personal name, GPS position, pictures;
(B) Represent a group or list for (A) so that others can add to this group or list one (A) of yours;
(C) Citation with bibliographic references included in the tags, so that excerpts from articles and books can be cited including the bibliographic origin of the citation in the event information;

It may be that the needs presented are satisfied by existing NIPS (maybe List kind 10015 for (B)? kind 1 with a tag for (C)?), as far as I researched I didn't find anything that I could be confident in using without presenting my need first.

Goals
I intend to implement a client where the purpose is for the user to interact with plants of common interest, so that they can contribute to their maintenance and enjoyment;

I am proposing (A) with the purpose of recording a specific plant or tree with GPS position, name;
I am proposing (B) to associate with an event (A) grouping information, such as species, family, biome, among others;
I am proposing (C) to help compose general technical information for (B), such as quotations of bibliographical references regarding the species;

As every Nostr event, (A), (B) and (C) can receive interactions, comments, boost, zap.

User experience

  • A very engaged user can publicly record a fertilization or pruning that he applied to a tree in his community;
  • An engaged user can publicly record the fruiting or flowering of a tree they have observed;
  • An ordinary user can subscribe to trees to receive notifications of their fruiting and flowering;
  • If a group of agriculturist wishes to use the system for private and custodial administration, they can do so by creating a private relay in they intranet;

Potential advantages for Nostr

  • Expand the diversity of clients, with different proposals;
  • Include important information in the relays, such as mapping plants of common interest;
  • Add a new niche of users to Nostr, people with interests in plants;
  • Including an argument to encourage the user to maintain a private relay (for plants on private property), the user being interested in the relay helps to strengthen Nostr's censorship resilience;

About the workforce

  • If approved by you, I can specify these NIPS and make them available for my work to be reviewed;
  • Having specified, following the implementation of my client, we would be available to implement the specification in nostr-tools;
@alexgleason
Copy link
Member

I love the idea. Not sure if it belongs in the official NIPs or not, but I hope you do it regardless.

@lordazzi
Copy link
Author

Thank you, I'm glad you loved my idea 🌳🍎.

I tried to propose notions of nips that are abstract enough so that they are not compatible with a variety of things beyond my business needs.

Maybe I should draft specifications of my NIPs in my repositories, implement them in my client and then propose them here?

My biggest concern is emitting events compatible with other clients and preventing events proposed by me from being matured and those I previously emitted from having their format discontinued (generating legacy), if at least in my specifications I have observations of those that maintain the Nostr protocol, I will feel more confident in the direction I take in my specifications.

@fiatjaf
Copy link
Member

fiatjaf commented Jan 15, 2024

Related: #952

@fiatjaf
Copy link
Member

fiatjaf commented Jan 15, 2024

Would something like this be of interest of biologists and people who like to take pictures of animals and classify them and stuff like that? I remember seing a website once for that.

https://www.inaturalist.org/ this one

@lordazzi
Copy link
Author

lordazzi commented Jan 15, 2024

Yes, it deals with the same niche of inaturalist, but the focus of this client is to identify wildlife to map it collaboratively and my proposal will be to map trees and plants of common interest to organize spontaneous maintenance and consumption.

But the use of event kinds that could compose my proposal can be used to compose a client with a purpose equivalent to inaturalist.

Here is an app in the model that I intend to implement for my nostr client:
https://play.google.com/store/apps/details?id=com.adarley1.fruitmap

@fiatjaf
Copy link
Member

fiatjaf commented Jan 16, 2024

Sounds good to me. I think you can start drafting a NIP as you work on the code and define event kinds and metadata necessary. Less text is better than more text. Specify fields only as necessary (more can always be added later, but removing is harder). You can open a draft PR to this repo if you want so others can see and provide useless feedback. Then when we have something more tangible to play with we can merge it.

@lordazzi
Copy link
Author

Understood, I will compose specifications that are objective and abstract enough so that they can be used by clients with different business demands, but with equivalent technical dependencies.
Thanks for the direction,
can this issue be assigned to me?

@fiatjaf fiatjaf assigned fiatjaf and lordazzi and unassigned fiatjaf Jan 16, 2024
@ionextdebug
Copy link

ionextdebug commented Jan 18, 2024

You can generalise it to create a global database of tags to identify concepts around the world.

Each concept can be linked to superconcepts.

Example:
Concept 1: Pink Rose
Concept 2: Rose
Concept 3: Flower
Concept 4: Vegetable
Concept 5: Concrete Concept
Concept 6: Abstract Concept
Concept 7: Concept

The Concept is the superconcept of Abstract Concept, that is the superconcept of Concrete Concept, that is superconcept of Vegetable, that is superconcept of Flower, and so on.

Why concept? Programming languages applies the word object to abstract or concrete things that have behavior or characteristics, and recently C++ (a programming language) introduced the term concept that is a more generic alternative to object type term. Also, the term concept is more generic and grammarly correct.

Each concept can be linked to another using a Doubly Linked List logic, a concept is linked to your father concept (superconcept) and to your children concepts.

A concept is build from requirements. If the thing have the requirements then it is matched with the concept (exactly concept or approximately concept).

As the concept use the Doubly Linked List logic, then the concept can change (for improvement) what is the his superconcept (to a more precise link building).

Beyond the requirements, each concept can have your own properties. A plant can have geolocalization properties, an idea can have another properties.

Another possibility, it's to create a set of appendix to the concept. For example, people around the world can append notes to each concept, these notes can be used to trading, recommendation, information, and etc.

This tool, with appendix, can be a super dataset for search engines, applications, AI, and etc.

Naive example:

"id": 000001, //a hash generate from the name maybe it's an option (Hash Table)
"concept": "Flower",
"properties": {
"color": "Pink",
},
"superconcept": "Vegetable",
"children": []
"appendix":[]

image

@lordazzi
Copy link
Author

Why properties instead specs like in NIP15?
There is a way to feed this appendix list and children list after publish this event?
Why don't associate superconcept with tag e: [ "e", "<id hexa event>", "superconcept"]?

@ionextdebug
Copy link

Why properties instead specs like in NIP15? There is a way to feed this appendix list and children list after publish this event? Why don't associate superconcept with tag e: [ "e", "<id hexa event>", "superconcept"]?

It's just an abstract idea. You can implement the idea according to your preferences.

@lordazzi
Copy link
Author

lordazzi commented Jan 19, 2024

I think of a Generic List for Nostr, if this idea is not prohibited, the idea would be to group events of different types, associating them in the list by referencing the list with an e tag and perhaps a keyword like listed.

I could call my list orange tree and I could customize a filter to search only for the concrete elements associated with it (orange trees with GPS and real ones) or I could configure a filter to list different references, bibliographies with sources citing characteristics and curiosities about orange tree.

With the generic list event I could compose a broader marketing structure for my NIP15 products than stall allows me, since with a generic list I can have a list of lists, being able to compose product showcases and add products to different galleries.

{
  "id": 1234,
   "kind": "GENERIC_LIST",
  "name": "orange tree",
  "description": "orange mmm juicy",
  "tag": [
     [ "t": "orange" ]
   ]
}

The quote is from another place, but it should not necessarily be considered something scientific, just something that is not available in the nostr to quote normally.

I can quote an excerpt from a children's book, I can quote a poem, an excerpt from a scientific article or the argument of a philosopher to compose a proposition that I am elaborating.

{
  "id": <id>,
  "kind": "UNNOSTRED_QUOTATION"
  "description": "roses are red, violets are blue, I like orange",
  "tags": [
     [ "q", "Book of poestry, page 2, second paragraph", "source" ],
     [ "q", "Cleiton", "author" ],
     [ "p", "<pubkey>", "author" ],
     [ "e", "1234", "listed" ]
  ]
}
{
  "id": <id>,
  "kind": "CONCRETE_THING"
  "name": "orange tree in my house",
  "description": "my orange tree",
  "tags": [
     ["g", "geohash" ],
     ["e", "1234", "listed" ]
  ]
}

It's not my final vision either, I still need to mature this vision.

@ionextdebug
Copy link

ionextdebug commented Jan 19, 2024 via email

@xeruf
Copy link

xeruf commented May 3, 2024

Just to throw in a consideration: (A) might be recorded within OpenStreetMap, and then nostr only tracks the auxiliary information by referencing the OSM ID.
But while we are at it, this could also accomodate tracking urban foraging - apps for that are currently rather centralized unfortunately: https://github.com/niccokunzmann/mundraub-android

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants