• 0 Posts
  • 32 Comments
Joined 8 months ago
cake
Cake day: August 17th, 2024

help-circle






  • It’s kind of an issue though if the documents cannot be understood by anyone but the lead dev.

    The one you mentioned is an exception though, most of the docs are quite easy to understand. Examples:

    https://codeberg.org/rimu/pyfedi/src/branch/main/docs/ADDING/_COMMUNITIES.md
    https://codeberg.org/rimu/pyfedi/src/branch/main/docs/ADDING/_USERS.md
    https://codeberg.org/rimu/pyfedi/commits/branch/main/docs/KEY/_TERMS.md
    https://codeberg.org/rimu/pyfedi/src/branch/main/INSTALL.md
    https://codeberg.org/rimu/pyfedi/src/branch/main/INSTALL-docker.md

    I suppose a weakness is that when it comes to the code itself, most of the explanation is on youtube rather than being written down, see https://join.piefed.social/2024/01/22/an-introduction-to-the-piefed-codebase/

    It looks to me a lot like those non-profit founders who explain nothing, make contributing hard,

    This reminds me of kbin. But I don’t think it’s quite fair to paint rimu the same way - he goes out of his way to help folks get set up and to encourage development.

    They say “help wanted” but if you believe it and contribute you’re going to get burnt out.

    Again, reminding me of kbin. But if you look at the pull requests though, there are many of the same folks contributing over a span of months, mostly with merged PRs. I can’t speak for any one of those folks, and burn out generally is a very real concern, but, not quite seeing evidence yet for this project specifically (though again perhaps I’ve overlooked something).

    Seeing the size and amount of features though, it’s already past prototype stage imo.
    When you don’t use one, you end up with a different code organization imo, and different affordances (eg more SQL views, several specialized data classes, a db layer that returns exactly what the program needs…)
    You always end up creating half a framework anyway … and so the questions are 1/ is it needed 2/ do you feel like designing one?

    These are good points. They remind me of the old debates about Minix vs Linux, the kernel. My guess is that since pyfedi is meant to be easy for beginners to understand and modify on their own, that this influences some of the design decisions made. But of course, even here, reasonable folks can reasonably disagree on what’s best.

    Honestly what irked me was mostly a succession of operations that weren’t in a transaction , and I also wondered why that wasn’t a trigger or a hook.

    Yeah, I don’t really know about this one. Your suggestions here make sense and wouldn’t clash with the “keep it easy for beginners” philosophy, so off the top of my head I can’t think of a reason why it was done differently - though perhaps I’d be able to understand it better if given more context.



  • Edit: hey I found this in the architecture document:
    What I tarnation is that project? This lack of test is literary on purpose?! Also reliability and security are this low?

    Only rimu can answer this. Note though that the architecture document you are citing from has only a single commit and the doc itself states that it’s a work-in-progress. So these are likely not binding guidelines, if someone wanted to add more tests and had a PR ready then I’m sure the devs would be open to discussing things.

    I’m also half-wondering if the scores don’t actually reflect rimu’s view of their importance to the project - but merely his view on how well the current codebase implements those features. Or perhaps just his own time commitment.

    why use a micro web framework when clearly the scope is a better fit for Django, and the devs don’t have the knowledge or time or energy to constantly refactor to keep the complexity under control?

    If it were up to me I’d probably keep it as Flask. As per https://www.greengeeks.com/blog/django-vs-flask-python-framework/

    Flask is known for its simplicity and flexibility
    Some argue that Flask enables faster development due to its minimal setup and flexibility

    This fits with my personal experience with both frameworks. Also keep in mind that rimu (as he states in the screencast in the README) wants this to be a project that is easy to build on top off and contribute to for folks who are newer to software development - my understanding is that the goal is to lower the technical bar so folks can get hands-on experience with developing for the fediverse more quickly and more easily.

    no tests?!

    Along those lines, adding unit tests can be a good way for someone new to a codebase to become more familiar with it.

    many 1000+ lines long files of python, a high level language

    But if you look at it, it’s mostly that there are a lot of small methods grouped together into a file, see https://codeberg.org/rimu/pyfedi/src/branch/main/app/activitypub/routes.py#L568 as an example.

    Even when dealing with a method that’s a big longer - e.g. https://codeberg.org/rimu/pyfedi/src/branch/main/app/activitypub/routes.py#L279 which is just under a hundred lines - they’re quite readable and it’s easy to see what each part of the method is doing.

    Of course they could be split up, and some developers have advocated for that sort of style generally - for example https://thoughtbot.com/blog/sandi-metz-rules-for-developers

    I think the current organization on pyfedi is reasonable, but it’s clearly not following the Sandi Metz rules.

    underused ORM (and I don’t like ORMs much)

    Not clear on what you mean by this. pyfedi uses SQLAcademy which is one of the more popular ones out there for python, so I wouldn’t call it underused.

    Or do you mean that pyfedi underuses SQLAcademy? But then, if you don’t like ORMs, wouldn’t this be a good thing?



  • Conclusion

    The Coexistion Protocol embodies a visionary approach to rethinking economic systems, focusing on fairness, transparency, and decentralization. While its principles resonate with the evolving landscape of decentralized technologies and the growing desire for equitable economic participation, the feasibility of its implementation is contingent on addressing several complex challenges. The success of such a protocol will depend on careful planning, user experience design, robust governance structures, and a willingness to adapt to the lessons learned during implementation.

    In summary, while the Coexistion Protocol presents a realistic and hopeful blueprint for the future, its practicality hinges on overcoming significant hurdles related to implementation, governance, economic sustainability, adoption, and regulatory compliance.


  • Challenges and Concerns

    1. Implementation Complexity: While the protocol aims to simplify decentralized systems, the actual implementation of a robust and efficient decentralized framework can be complex. Ensuring scalability, security, and user-friendliness will be significant challenges, especially as the system grows.

    2. Governance and Decision-Making: Achieving true democratic governance in a decentralized system can be difficult. Ensuring that all voices are heard and that decisions are made effectively without falling into the trap of inefficiency or gridlock is a critical concern. The proposed consensus-based decision-making might face challenges in practice, particularly in larger groups.

    3. Economic Viability: The non-speculative value system represents an interesting shift from traditional economic models. However, establishing a stable and sustainable economic model that rewards contributions equitably while preventing exploitation and ensuring long-term viability is a complex task. The challenge of ensuring that value is accurately tracked and distributed can be significant.

    4. Adoption and Transition: The transition from traditional economic systems to a decentralized framework like the Coexistion Protocol will require significant cultural and systemic shifts. Gaining buy-in from established institutions, businesses, and individuals accustomed to traditional hierarchical structures may be challenging. Moreover, potential resistance from those who benefit from the current power dynamics may hinder adoption.

    5. Regulatory Environment: Decentralized systems often face uncertain regulatory landscapes, and the Coexistion Protocol would likely attract scrutiny from regulators. Navigating legal frameworks while maintaining the principles of decentralization and inclusivity could be a significant hurdle.

    6. Technological Barriers: The reliance on technology means that access to the Coexistion Protocol could be limited for those without the necessary digital literacy or access to technology. Ensuring equitable access to the system will be crucial for achieving its goals.


  • The Coexistion Protocol presents an ambitious vision for a decentralized economic framework aimed at fostering fairness, transparency, and inclusivity. Its goals of equitable work allocation, decentralized governance, and a non-speculative value system are indeed compelling and align with ongoing trends in the digital economy, particularly those driven by blockchain technology and decentralized autonomous organizations (DAOs). However, while the concept is innovative and appealing, several factors must be considered regarding its feasibility and realism.

    Strengths and Opportunities

    1. Decentralization and Transparency: By leveraging blockchain and decentralized governance models, the protocol can enhance transparency and trust among participants. This is a crucial element in today’s economic environment, where trust in institutions is waning.

    2. Merit-Based Allocation: The emphasis on merit-based work allocation can potentially democratize access to opportunities, allowing individuals to participate and thrive based on their skills rather than their connections or backgrounds.

    3. Integrated Education: The focus on embedding education and skill development within the economic framework is particularly relevant in addressing skill gaps and preparing workers for evolving market demands.

    4. Collaborative Ownership: The idea of shared ownership and collective responsibility can foster a sense of community and shared purpose, encouraging collaboration over competition.






  • I appreciate that you want honest discussions,
    Then I looked through some of your other takes and intentionally voted it down because I thought you were in the wrong

    So this is exactly why I ask - I’m curious then as to what you thought was wrong. One comment that got downvoted was me thanking another commenter for an explanation behind Schumer et al, and another was just me asking someone else about their downvote - so presumably there’s a diverse range of viewpoints and opinions that you could share here. And if you chose to do so, I look forward to a thoughtful and engaging discussion on them.

    I reverted my original downvote because it was not intentional.
    do I really need to care whether or not you let anything “go”.

    Well, I just meant that I don’t usually ask for folks to reverse or revert their downvote if it’s a misclick or some other accidental thing. Getting a downvote undone is actually pretty rare in this case.

    but policing other people’s reactions

    I’m asking for an opinion, not policing them! That’s more like in lemmy.world/c/politics (where mods had explicitly set up the rule that you shouldn’t downvote just because you disagree - see rule no. 5 there).

    I mean, you can see that I didn’t even downvote you back in retaliation.

    That being said, I need not careful

    Not when it comes to me, to be sure. I don’t police and often don’t even downvote back as I wrote above. And of course I have no objections to you downvoting as long as it’s done intentionally - it’s just another way to express your opinion. (I just like asking why since it’s a chance to have a good discourse and maybe learn something.)

    But in general, I do think one should be careful to avoid downvoting by misclicking or otherwise by accident - downvotes and upvotes are public and folks are trying to figure out how to use this to make bots that check for other bots, autoban users (I think st.itjust.works is already using one) and so on. So being careful and deliberate with your up and down votes is helps to avoid getting caught in some kind of dragnet.

    is really just your reaction to someone else’s content

    This part, I didn’t understand.

    does not help you attain your goal.

    My gut feel on this is that:

    2 out of 10 times, the downvoter doesn’t respond to my post (explaining the reason for downvoting isn’t obligatory on most magazines after all), so I don’t gain anything (but neither do I seem to lose anything just by asking).

    1 out of 10 times, the downvoter downvoted because they legitimately disagree, but we both end up particpating in a good convo about the issue.

    3 out of 10 times, the downvoter misunderstood what I said, but wouldn’t have downvoted if I had gotten the point across in the beginning.

    4 out of 10 times, it’s just an accident.

    So 8 out of 10 times I attain my goal. I think that’s a pretty good track record, don’t you?



  • Basically I’m in the same boat as AOC and all the folks feeling betrayed, and I’m skeptical of Schumer’s intention because the news articles I’ve browsed over don’t include any detailed reasoning on why Schumer voted the way he did - but others on this thread have since provided a decent explanation.

    And … when folks reply to me saying that my point is unclear, I’m always happy to clarify my meaning. Typically, that engagement turns out to be fulfilling on both ends.

    A lone misclick isn’t a big deal - accidents happen and technology can sometimes be hard to use, so I tend to let these go. That said, I noticed that after writing your reply, you went ahead and downvoted three more of my comments on this post… so please try to be more careful with the misclicking. Especially considering that downvotes are essentially public.