Nostr allows for distributed entrepreneurship.
Big tech companies have no incentive to invest in locking a user base in a distributed value-sharing protocol since the users can seamlessly migrate with their data to the next value supplier.
This allows many micro-entrepreneurs to cater to the audience previously crowded out by said big tech. The network rapidly judges these many small products by their value to and interconnection with the entire network of users and other products. This distributed entrepreneurship process increases value for all at an ever-increasing rate.
The Nip is ready. I would be happy for review and feedback: https://github.com/ofer-elrom/nips/blob/master/66.md
I think Trade support at the Nostr protocol level is the next big step to take.
For anyone reading this and want to build:
Clients can facilitate the connection between Point Of Sale service suppliers and users acting as sellers and get part of the payment for that facilitation.
To do that client can supply the UI to let users create Product events (see below) connected to a POS supplier.
Clients creating product events incentivize all to cooperate around the decentralized protocol with no one centralizing control. It provides Clients with a revenue stream sustained by the real need of their users.
Trade support can be composed of the following:
`product event` containing data of product offered and URL to POS supplier.
`Skills And Products` tags added to set_metadata event of users acting as sellers.
`Rating event`
Consider, for example, cooperating with Breeze as a POS supplier on Lightning.
I am writing a NIP for this that I hope can help.
I think Trade support at the Nostr protocol level is the next big step to take.
For anyone reading this and want to build:
Clients can facilitate the connection between Point Of Sale service suppliers and users acting as sellers and get part of the payment for that facilitation.
To do that client can supply the UI to let users create Product events (see below) connected to a POS supplier.
Clients creating product events incentivize all to cooperate around the decentralized protocol with no one centralizing control. It provides Clients with a revenue stream sustained by the real need of their users.
Trade support can be composed of the following:
`product event` containing data of product offered and URL to POS supplier.
`Skills And Products` tags added to set_metadata event of users acting as sellers.
`Rating event`
Consider, for example, cooperating with Breeze as a POS supplier on Lightning.
I am writing a NIP for this that I hope can help.
Global search on Nostr data
-----------------------------
It is hard to do a global search on all Nostr data since:
- Data is spread between disconnected and unpublished relays.
- The decentralized approach does not allow for a central entity that indexes all data.
A possible approach to distributed indexing that allows global search is `indexing events`.
These events can be linked to one another, forming a mesh that indexes relay data across relays.
Adding monetization by charging the readers of these events can incentivize indexers to create such events and push them to relays.
The "only" thing left is to think of the data scheme that allows mashing events into various cross relays data indexes.
It could be interesting to think of implementing this with indexing events. These may be events that are linked to one another in some manner forming a mesh that indexes relay data across relays.
If we can add monetization by charging the readers of these events it can insentivize indexers to create such events and push them to relays.
Then "all" that is left is to think of the data scheme that allows mashing events into various indexes of data across relays.
Building our future is a very appealing road to take.
I think Trade support at the Nostr protocol level is the next step on that road.
For anyone reading this and want to build:
Clients can facilitate the connection between Point Of Sale service suppliers and users acting as sellers and get some part of the payment for that facilitation.
To do that client can supply the UI to let users create Product events (see below) connected to a POS supplier.
This supplies an incentive for all to cooperate around the decentralized protocol with no one centralizing control, and it provides Clients with a revenue stream sustained by the real need of their users.
Trade support can be composed of the following:
- product event containing data of product offered and URL to POS supplier.
- Rating event
- Skills And Products tags added to set_metadata event of users acting as sellers.
Consider, for example, cooperating with Breeze as a POS supplier on Lightning.
Building our future is a very appealing road to take.
I think Trade support at the Nostr protocol level is the next step on that road.
For anyone reading this and want to build:
Clients will facilitate the connection between Point Of Sale service suppliers and users acting as sellers and get some part of the payment for that facilitation.
To do that client can supply the UI to let users create Product events (see below) connected to a POS supplier.
This supplies an incentive for all to cooperate around the decentralized protocol with no one centralizing control, and it provides Clients with a revenue stream sustained by the real need of their users.
Trade support can be composed of the following:
- product event containing data of product offered and URL to POS supplier.
- Rating event
- Skills And Products tags added to set_metadata event of users acting as sellers.
Consider, for example, cooperating with Breeze as a POS supplier on Lightning.
See more in this note @#note1xvshv5m.
Link to Breeze: https://breez.technology/
I think the way forward is Trade support at the Nostr protocol level.
Then the client will facilitate the connection between the Point Of Sale service suppliers and the user acting as seller and get some part of the payment for that facilitation.
The client can supply the UI to let users create Product events (see below) connected to a POS supplier.
This supplies an incentive for all to cooperate around the decentralized protocol with no one centralizing control, and it provides Clients with a revenue stream sustained by the real need of their users.
Trade support can be composed of the following:
- product event containing data of product offered and URL to POS supplier.
- Rating event
- Skills And Products tags added to set_metadata event of users acting as sellers.
See more in this note @#[3].
Consider cooperating with Breeze as a POS supplier on Lightning.
Jeff Booth invested in Breeze, so maybe he can help connect to them #[2]
yessir. the dedicated server is ready to go, domain is there, with respect design and stitching of NIPS and integration with other tech, we're at the pen and paper stages, but the idea has been thought through for about a decade now, and have been waiting for the socio-economic trends to be "the right time to release." It is now needed.
Idea is to combine IRC/webRTC based IRC with a channel unique to each user, generated on the users nip05 address. in my case, it'd be #ringo_nostr-check.com for example.
-the site will function much like an iris.to, or nostrgram.co, but will be in the realm of jester.io where it's a specialized set of functions and serves as a web app running nostr protocols - thus:
-a user may enter the site, search via engine for "piano lessons," or "heirloom tomatos," or "talk therapy" - nPubs with those skills listed on their profiles will be returned in the search result. much like iris.to has sections for "following," "direct messages" and "global" willtrade.org will have a section for "my active agreements" and "my skills for barter and trade" shortened to "my skills" for UI purposes.. and another section for "free stuff." which is exactly as it sounds.
-a user may then enter the channel of that user, and negotiate their barter/trade through chat. the reason for IRC is primarily because not every single aspect of the discourse needs be recorded in NIPS, only the final agreement. doing it like this in IRC, gives other users the ability to watch barter and trade in action, if they are curious, so they can learn how it flows, empowering them.
-when a user wishes to encapsulate the final proposal for agreement with the person they are in discussion with, they issue a command in the channel as "/finalize-trade" and then they write out in the channel what the trade is for, and the terms.
-The "/finalize-trade" command wakes up the unrealircd plugin and it connects to the channel for scraping the last message, which is the finalized agreement, to be published as a new note, to be listed under "my active agreements" section."
the plugin bridges all this, generates a new note for each user, putting it under "my active agreements."
--- parties carry out the trade in real life
--- parties can @reference the note after the agreement has been carried out, by replying to it, to leaving feedback on how it went.
-willtrade tracks the progress looking for a keyword such as "positive" "negative" or "neutral" and assigns an internal reputation score to the user based on how the trade went, via this feedback. This could be as simple as user1 liking the note on party 2's profile, once the agreement is carried out. This would count as a successful agreement to the site, and would then reflect in that users + count for their reptuation score.
-reptuation score is computed and displayed at the top of a users profile.
-link to chat with that user which will drop them into the appropriate channel to discuss trades with that user, is also at the top of their profile.
(a few more details,) but this gives a much clearer idea of what I'm seeing and where it's presently at.
concurrently published to https://writehere.is/nwo/054-2023-willtrade-design-conceptualization-md
#[11]
#[12]
#[10]
# please review the above, and thank you.
Thank you for the elaborate explanation. I don't understand the need for the negotiation process, but I will read deeper later.
IMO, finding a way to have as much of the logic reside in the Nostr protocol in the form of a data scheme laid over events and profiles is vital.
This will allow the use case you described and many other use cases to run over the data and strengthen each other, like what is happening with the current social media use cases of the Nostr protocol.
These are roughly the changes I think are required at the protocol level to enable this:
In short:
Adding a Product type Nostr event that describes a tradable product.
Adding skills as a possible property list of a user profile.
Adding Rating type Nostr event that rates a product or a skill.
In longer form:
Products
========
Product Event
- High-level type of product - Good, Service, ...
- [categorie1, categorie2, categorie3, ...] categories the products fits into. For an apple, this may be ['food', 'fruit', 'ready to eat food', ...]
- ID: Unique Pubkey Id of this product
- Description in text
- Description media - image or video
- Price value
- Unit of account that the price quotes - Bitcoin, Dollar, ....
- Purchasing process URL. Calling this with the product ID redirects to a purchasing page.
Social rating
==========
Rating event
- Rating value
- Rating range [min max]
- [Skill: skill that is being rated, Profile ID: Profile to which this rating applies]
- Item id: the item that is being rated.
- Rater ID. The ID of the user who gives the rate
- Commen
Division of labor
=============
Add the to set_metadata event. Note that this is only for a user who is a seller of goods or products.
- [skill2, skill2, ] skills that the user proclaims. Skill may be in the service category (marketer, developer) or in the product supplier category (cloths store, electronic device store,... ). Profile skills may be rated by other users who will send rate events
- [product1, product2, produ3] - Ids of products supplied by the use
it’s the real attack on all open source/free software https://twitter.com/digitalnaut/status/1628775636482379776
Making synchronization of code versions and developer interactions censorship-resistant and keeping developers' real identities hidden can solve this. @jack bountied a project for this.
To whoever is going to build this, please consider using the following as part of the solution:
Wrap monetary support in coders with a Fedimint community to prevent following the money trail to them.
Have Nostr-authenticated developers use a Nostr-compatible git client to push to and pull from Nostr-authenticated git suppliers using Nostr relays as a communication layer.
For a more elaborate explanation, please see and remark in this google document:
https://docs.google.com/document/d/1z96XpTtrUvrFZYPjMzlT5JuE41HF6X5vI99lvImVCvU/
I think "Trade" support at the protocol level of Nostr is a significant step toward being a base layer for human cooperation.
I was thinking about the NIPs required to support something close that is more focused on a gig marketplace. I would be happy to define a set of NIPs that supports both and to try and cooperate in creating some proof of concept on that.
I think "Trade" support at the protocol level of Nostr is a significant step toward being a base layer for human cooperation.
I was thinking about the NIPs required to support something close that is more focused on a gig marketplace. I would be happy to define a set of NIPs that supports both and to try and cooperate in creating some proof of concept on that.
Nostr supplies a low-risk sandbox to find the benefits of a decentralized self-forming system for human cooperation.
Newcomers get the easy-to-pick fruits and, by picking them, send a signal to builders.
Builders can then dig deeper into how the system forms and reform it according to that signal.
All with rapid reiterations and short feedback loops.
Thanks.
In Nostr, that central administrator does not exist, so no one can pay for bypassing the social power structure.
I think that as long as you need to distribute money between influencers to get exposure and these influencers are bound to have integrity towards their crowd, or they lose that crowd, then such network promotion may strengthen the clear signal of value in a community and follow the "natural" formation of a social structure.
The problem starts when you pay a central platform administration to overexpose a message by breaking what the self-forming social structure dictates.
#[0]
We just released the beta version of Current App… Please include in your report.
Current App now supports all Zap functionality..
- Zap within the App without going to another wallet App
- See zap per post, total amount and separated in replies
- Receive Zap for your post from other clients such as Damus or Snort.social
- Available on Google and Apple store using testing links
- iOS - https://testflight.apple.com/join/z5S1f7ql
- Android - https://play.google.com/apps/testing/io.getcurrent.current
- If you had trouble setting up and receiving zaps then current makes it simple and easy..!
Is it possible to connect an existing Nostr pubkey with the App?
I couldn't figure out how.
The winning apps on this protocol will be the ones that optimize how people on them cooperate with other people to achieve a common goal.
As long as the apps depend on people for their "computation," centralized power will be in check, and the good of the community of participants will be aimed for.
Just as is currently happening with Nostr social clients.
The winning apps on this protocol will be the ones that optimize how people on them cooperate with other people to achieve a common goal.
As long as the apps depend on people for their "computation," centralized power will be in check, and the good of the community of participants will be aimed for.
Just as is currently happening with Nostr social clients.
Nostr, as a base layer software protocol for communication between people, incentivizes applications that discover the most rewarding human cooperation. And then enhance.
Internet protocol connects machines and leads to the unprecedented continuous optimization of what computers can do together. Nostr protocol connects people and can lead to the unprecedented continuous optimization of what humans can do together.
Imagine what this incentivizes.
Internet protocol connects machines and leads to the unprecedented continuous optimization of what computers can do together.
Nostr protocol connects people and can lead to the unprecedented continuous optimization of what humans can do together.
Imagine that!
Nostr is exploding with growth. The total amount of pubkeys writing events has passed 2 million. We're fast approaching 20 million total events published.
https://void.cat/d/AoniwoWd79pqbwQx4JdmNc.webp
https://void.cat/d/HaHsnHhwhqbEKbzz545ogd.webp
You can view all of the statistics yourself here: https://nostr.band/stats.html#total_users
Internet protocol connects machines and leads to the unprecedented continuous optimization of what computers can do together.
Nostr protocol connects people and can lead to the unprecedented continuous optimization of what humans can do together.
Imagine that!
Internet protocol connects machines and leads to the unprecedented continuous optimization of what is achievable by machine cooperation.
Nostr protocol connects people and can lead to the unprecedented continuous optimization of what is achievable by human cooperation.
Imagine that!
We need censorship-resistant open source development.
IMO we can get it with the correct implementation of GitHub capabilities over Nostr.
In Short -Nostr-authenticated developers can use a Nostr-compatible git client to push to and pull from Nostr-authenticated git suppliers using Nostr relays as a communication layer.
I am not sure I have the time to create this on my own. I would appreciate any remarks on this and help get more people on board with the idea.
For a more elaborate explanation, please see this google document: docs.google.com/document/d/1z96XpTtrUvrFZYPjMzlT5JuE41HF6X5vI99lvImVCvU