nostr-protocol / nips

Nostr Implementation Possibilities
2.34k stars 564 forks source link

NIP for fruit tree and flowers #990

Open lordazzi opened 8 months ago

lordazzi commented 8 months ago

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

Potential advantages for Nostr

About the workforce

alexgleason commented 8 months ago

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

lordazzi commented 8 months ago

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 commented 8 months ago

Related: https://github.com/nostr-protocol/nips/pull/952

fiatjaf commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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?

ionextdebug commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

I believe that you need to do this in a profitable way for relays. It's an opinion.

A tool to people search and negotiate things of a type.

On Fri, Jan 19, 2024, 3:33 PM Ricardo Azzi Silva @.***> wrote:

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": , "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", "", "author" ], [ "e", "1234", "listed" ] ] }

{ "id": , "kind": "CONCRETE_THING" "name": "orange tree in my house", "description": "my orange tree", "tags": [ ["g", "geohash" ], ["e", "1234", "listed" ] ] }

— Reply to this email directly, view it on GitHub https://github.com/nostr-protocol/nips/issues/990#issuecomment-1900993969, or unsubscribe https://github.com/notifications/unsubscribe-auth/BDA5HIK7UROCPNWVRWTAFDDYPLDAFAVCNFSM6AAAAABB3EXR3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBQHE4TGOJWHE . You are receiving this because you commented.Message ID: @.***>

xeruf commented 5 months ago

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