silverpill

@lukeprofits I think your application can be better described as "payment scheduler", and you're right about "monero payment code" sounding confusing. Maybe "monero scheduler code"? Or "monero payment request"?

Also, I'm still interested in implementing code generation in my project. The only blockers are portability issues that I previously reported.

@WishfulAlbatross

>2. Decentralized Governance

CHIP process is quite complicated and seems to be focused exclusively on network upgrades. Also, calling it decentralized is misleading because some group of people has to oversee the process, maintain the repository etc etc

But I agree that setting up something like RFC for Monero ecosystem is a good idea, because it will improve coordination and transparency. Someone even tried to start it back in 2014 (and failed): https://github.com/monero-developers/mips

Such project would require some support from the community (to avoid the fate of the previous MIPS initiative), but I think it's doable. In Fediverse we have FEP process, which is very lightweight and can be used as a template.

@monerotalk did:xmr requires downloading the blockchain to perform the verification, right? So it's not lightweight. Also I found the github repo but there is not much info: https://github.com/benedictvscriticus/did-xmr/tree/main/2023-06-Monerokon. Has any progress been made since the presentation at Monerokon?

That being said, I like the idea of selective disclosure and I might even put this DID method to practical use if it will be properly specified.

cc @MoneroTalk

@moneromaxi Can Lemmy users follow users of other software? As far as I know, this is not supported, and that means XMR subscription from Lemmy account won't work either.

This is an interesting idea though.

@gvs @simplex @ShadowRebel @k4r4b3y True, but as far as I know there is a single team and single implementation, so it's not quite in the same league as Matrix and XMPP.

@k4r4b3y @ShadowRebel Matrix seems to be focusing on the needs of its corporate clients lately. Interesting projects like P2P matrix, low-bandwidth and portable identity are not getting attention. Instead, they are making OIDC mandatory:

https://matrix.org/blog/2023/09/better-auth/

Over time I've become less enthusiastic about Matrix. I'm not saying we should ditch it, but it's good to have a FOSS-oriented alternative (XMPP), just in case.

@k4r4b3y @ShadowRebel Yes, self-hosted Tor instance is a way to go if you want to be completely independent. People who don't self-host can link their account to a public key and move to another instance if something bad happens, this is also supported (still experimental and undocumented though; I'll try to find some time to write an explainer).

Finally, the protocol can be extended to support nostr-like architecture with simple relays and rich clients. Maybe I will implement that too, or somebody else can start such project.

@RealPappenheimer This issue was discussed at length in monero-community matrix room when proposal was submitted. I guess it's too late to reverse the decision. Even the person who wrote AGPL-licensed modules appears to support the change, although I don't know why they suddenly changed their mind.

@Ferminho @maegul This proposal describes a very simple marketplace, and some things were intentionally left out. However, it is based on Valueflows system which can be used to describe many different economic processes, including planning, production and transportation:

https://www.valueflo.ws/introduction/core/

So developers may use object types and properties defined there if they want to build something more complicated. And social interactions can be represented as standard ActivityPub activities. I think Valueflows and ActivityPub nicely complement each other.

@kowalabearhugs Currently, some parts of Cuprate are licensed under AGPL-3. This means anyone using this code should keep their derivative works as open source and use the same license. The license protects the project from hostile forks and generally serves as a deterrent against privatization of public goods. Lemmy, Mastodon and many other Fediverse servers use AGPL-3 license and it is totally reasonable choice for Cuprate too.

However, when this CCS proposal was discussed some people started to push aggressively against AGPL (going as far as calling it "legal nightmare") and the developer agreed to change the license and even agreed to re-write AGPL-licensed parts of the application if needed.

As I said, this is a mistake, and makes Monero weaker. I think Cuprate may eventually become a dominant implementation because Rust provides a better security and developer experience, and a big chunk of modern cryptographic libraries is being written in Rust (especially in zero-knowledge cryptography). But now any company can safely use Cuprate as part of their infrastructure because it has business-friendly license, create a closed-source fork and hire developers who were previously working on open-source version.

The change of license is basically a signal that corporate interests are more important than interests of ordinary users. As for examples of where this attitude leads, see any cryptocurrency project where companies or "foundations" pay developers for their work and therefore shape the product. Exceptions are rare, and Monero is one of few that relies on donations and crowdfunding.

@Rucknium

>All code produced for this CCS will be licensed under MIT.

The decision to change license from AGPL to MIT was a mistake. And what is particularly concerning, apparently a lot of people are okay with that.

Such attitude led to demise of many other communities where independence was sacrificed for "adoption" and corporate takeover was perceived as a good thing.

@Emperor @MostlyLazy If the server doesn't process payments it should not cause admin a headache in most (?) jurisdictions.
Alternatively, one could focus on grey markets.

>Bitejo

By the way, Bitejo was planning to add federation, although now the future of the project is a bit uncertain. It might be added to Bitejo fork, as I suggested in this CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/395#note_21836