Factomize is considering becoming a development ANO

Secured
#1
I was recently able to talk an old colleague of mine into working with me again. He's an outstanding developer who worked with me and Mike Miller (Daitengu) at companies I ran in the past with great success. I find myself mostly twiddling my thumbs these days and want to produce more for the protocol. However, our being at 60% efficiency and with the price of FCT so low, the funds aren't there to do development. We are considering lowering our efficiency and here's some of the short term projects we'd create with an eye on a huge EC consuming prize in the future.

Please note that the intention of Factomize is to one day turn this forum over to the eventual Factom Foundation non-profit. We have begun early discussions with DBGrow about the forum being moved to their neutral site they're going to develop. As such, while what we create could be viewed as us having too much control over important information, that is not our intention or goal.

As you can see below, most of these modifications would result in increased EC usage.

1. There has been discussion about requiring specific time frames for discussion of topics and then specific time frames for votes on those topics. These types of requirements can be hard to keep track of. We would automate this process where when you create a certain type of topic that has a requirement for discussion and voting, the system automatically creates the discussion / vote with the required time periods. Email notifications would be sent to all pertinent parties warning them of deadlines.

2. When I tag a user by doing @[username] instead of a simple alert, that person would also be emailed. A new chain would be created on Factom for that alert which would create a timestamp. When the user viewed that alert on the forum, another entry would be made with the timestamp and it would show that user had viewed (or not viewed) that alert within the thread. This would improve communication, transparency, and avoid potential, "I never saw it" claims. Public statistics would be kept showcasing who views their alerts and who does not.

3. Build an ANO and Guide Agenda and Meeting Minutes system into the site. With a single click, they can be Factomized.

4. Factomize all polls on the forum. Each poll would have its own chain and after every vote and vote change, a new entry would be made.

5. Create the ability to have @[Authority Node Operator] and @[committee] alerts. Like number 2 above, instead of a simple alert, all members would also be emailed. A new chain would be created on Factom for that alert which would create a timestamp. When the users viewed that alert on the forum, another entry would be made with the timestamp and it would show that user had viewed (or not viewed) that alert within the thread. This would improve communication, transparency, and avoid the, "I never saw it" claims.

6. Factomize all "attached files" to forum posts. All uploaded content to the forum would be Factomized. It would in essence be a built in freefactomizer.com.

7. Create a system that tracks ANO pledges, update to their pledges, and a host of other information about ANOs that ANOs can update.

8. Create an "ANO Only" area of the site that provides a host of information that will especially be important for newly elected ANOs so they can get up to speed and make sure they're quickly integrated.

9. Thread by thread permissions. This has been requested by multiple people. Specify who can reply to, edit, etc a specific thread.

10. A more robust committee system and a committee page that shows current membership and lets people know how they can join.

We have a host of other ideas we'd like to develop and are open to other ideas that will help improve communication, transparency, and efficiency for this protocol while increasing EC usage.
 
Last edited:
Secured
#2
Which efficiency you suggested & how long time? Most developers ANOs operate at 50% efficiency.

Even we could operate at 50% if being pure dev ANO (additional 15% in our case are spent on PR/marketing in Russia & new clients integrations).

P. S. I like you effort and not critisizing it (the opposite — I support it, David), just want to find out.

We shouldn’t forget that lowering efficiency to cover [n]K USD expenses fully depends on FCT/USD and in current market conditions we should be very very accurate with it — e.g. if FCT price is $3, it’s better to save the efficiency and allow grant pool to be increasing, instead of collecting additional $3K USD.
 
Secured
#3
Another idea — is community help with this development free of charge.

De Facto are able to code some features in this list for free ;) I hope other dev ANOs could do the same — especially when we have already developed library for factomd by CL, new factomizing functions shouldn’t be the big problem.

But I don’t push on other ANOs — it’s volunteer.
 
Last edited:
Secured
#4
And a little offtopic, but very important thing to discuss — how to promote existing addon and its usage.

We have already published xenforo addon in public repo which factomizing threads and posts, but as I saw in Explorer — nobody’s except Factomize using it. And it’s not because off idea/implementation are bad — both idea and implementation are brilliant. The problem is lack of marketing, and on my mind we need to promote current addon and get it installed on more forums.

Have you published it on XenForo dev forums or somewhere else? I kindly ask Marketing committee for help with the addon PR.

P. S. Wish I have @Marketing alert here ;)
 
Last edited:
Secured
#6
Is there a market for this kind of solution? Do you have any interest from people running public forums? If yes, why are they not using the xenforo addon at the moment? How much would it cost monthly to run - let's say - a forum with 100k members on factom protocol? thank you
 
Last edited:
Secured
#7
Which efficiency you suggested & how long time? Most developers ANOs operate at 50% efficiency.

Even we could operate at 50% if being pure dev ANO (additional 15% in our case are spent on PR/marketing in Russia & new clients integrations).

P. S. I like you effort and not critisizing it (the opposite — I support it, David), just want to find out.

We shouldn’t forget that lowering efficiency to cover [n]K USD expenses fully depends on FCT/USD and in current market conditions we should be very very accurate with it — e.g. if FCT price is $3, it’s better to save the efficiency and allow grant pool to be increasing, instead of collecting additional $3K USD.
There are a lot of ANOs who currently have a set efficiency of 50%, but I'd argue none in western countries are operating at 50%. And by operating I mean paying the bills. At current prices 50% efficiency gets you $7,220 per month. Even if you had no other expenses (everyone of course does) and paid all of that to a developer, that's $86,620 per year. MAYBE you'll get a junior programmer for that, but certainly not an experienced developer; the type of developer who enables companies to be successful. If we hired the top tier developer we speak of and operated at 50% efficiency at $6.5 FCT, we'd be in the red $2,293 per month. And that's with me not taking a penny in FCT or $$.

And that's one of the many issues with efficiency. It's fine when the price of FCT is high, but there's so much social pressure to maintain efficiency that most ANOs won't lower even when they can't cover their bills. And that's not going to end well. We've hamstrung ourselves by dictating a static efficiency for a highly volatile asset we depend upon to fund ourselves at this juncture. It was a terrible idea. Only BIF saw the writing on the wall as they wrote in a clause for a variable efficiency and even they are too concerned about the social ramifications to lower despite it being part of their campaign document. I saw some of the writing on the wall but what I didn't anticipate was the Protocol being in its current state this long after M3.

Factomize would operate at a variable efficiency of between 0% and 70%. If FCT goes lower, we'd lower to cover our expenses. If FCT goes higher, we'd raise our efficiency.
 
Last edited:
Secured
#8
There are a lot of ANOs who currently have a set efficiency of 50%, but I'd argue none in western countries are operating at 50%. And by operating I mean paying the bills. At current prices 50% efficiency gets you $7,220 per month.
So why not use grant pool to get the needed amount of money for this development?

We have already created a precedent for lowering effieciency. Imagine if all ANOs will start lowering their efficiencies because off it’s not enough to covers bills for development and whatever else. Uncontrollable. Up to 0. Whole grant system and FCT price will be depressed.

It’s a negative trend on my mind, and if we can avoid it by using grants — we definitely must do it.

Please don’t take it personally, I like this effort and what have already done for community and I just want to figure all out.
 
Secured
#9
Another idea — is community help with this development free of charge.

De Facto are able to code some features in this list for free ;) I hope other dev ANOs could do the same — especially when we have already developed library for factomd by CL, new factomizing functions shouldn’t be the big problem.
One of the things I've been pushing for in public and private since the time I became a Guide is for developers like Adam Levy and Paul Bernier (Luap) to be supported by the community in whatever way they need. I've been pushing for this because I know talented individuals when I see them and I know damn well it's critical these individuals be able to develop full time for this protocol. There are few things more important than bringing quality developers into this ecosystem. There's a reason I didn't put forth this idea until now: I hadn't talked my old star developer into coming out of retirement. I had a good dev at my disposal, but not great.

The initial projects I propose will be useful. They'll help solidify a shaky communication and governance foundation and improve efficiency. They'll also kick up EC usage a bit. But there's more to my strategy than that. I'm also using those projects to bring my developer up to speed as he hasn't worked on blockchain before. And some of those projects will also play into our future strategy.

There's a lot of strategy at play here with the end goal of bolstering this protocol in a myriad of ways.
 
Last edited:
Secured
#10
And a little offtopic, but very important thing to discuss — how to promote existing addon and its usage.

We have already published xenforo addon in public repo which factomizing threads and posts, but as I saw in Explorer — nobody’s except Factomize using it. And it’s not because off idea/implementation are bad — both idea and implementation are brilliant. The problem is lack of marketing, and on my mind we need to promote current addon and get it installed on more forums.

Have you published it on XenForo dev forums or somewhere else? I kindly ask Marketing committee for help with the addon PR.
We haven't released it anywhere beyond publishing the code nor do we plan to. It's a great PoC and as you've seen, people like yourself can make use of it. But for the end user, releasing and supporting it for the limited number of users who would utilize it would not be worth the effort. It would be a distraction.
 
Secured
#11
And I have to ask @Niels favourite question — why this development can not be funded by grant?

There are clearly clarified tasks and one-time grant fits perfect for all this.
It could be but I'm not interested in waiting around for the next grant round and I worry my developer wouldn't be available by that point. The grant system in its current state creates far too much uncertainty for a company trying to get shit done.
 
Secured
#12
Is there a market for this kind of solution? Do you have any interest from people running public forums? If yes, why are they not using the xenforo addon at the moment? How much would it cost monthly to run - let's say - a forum with 100k members on factom protocol? thank you
I think the current market for decentralized forum software or software that performs the function the Factomize Forum Addon performs is small. It's part of the reason we haven't released the current addon and don't plan to. The reality is, at present, most normal people don't really care about immutability and all the potential benefits of blockchain.

If the project I mention ended there, it would not be worth the resource expenditure. But I'm leaving out very important variables. To give a little backstory, the developer I am looking to hire and I created decentralized forum software solutions in the past (pre Bitcoin before decentralization was cool). While the assets we created were eventually acquired, the reality of the situation is, we made a few critical strategy mistakes that resulted in our company not being a household name. I won't make the same mistakes again.
 
Last edited:
Secured
#13
So why not use grant pool to get the needed amount of money for this development?

We have already created a precedent for lowering effieciency. Imagine if all ANOs will start lowering their efficiencies because off it’s not enough to covers bills for development and whatever else. Uncontrollable. Up to 0. Whole grant system and FCT price will be depressed.

It’s a negative trend on my mind, and if we can avoid it by using grants — we definitely must do it.

Please don’t take it personally, I like this effort and what have already done for community and I just want to figure all out.
I'm not taking it personally.

If ANOs are contributing in meaningful ways and need to lower efficiency to cover their bills, then they should. If a BIF can do more by lowering their efficiency and selling some FCT, we should support that. We're all kidding ourselves if we think that using grants instead of lowering efficiency somehow doesn't affect the price of FCT. That FCT is going to get sold sooner or later so I suggest we not be afraid to utilize our resources to create a solid foundation to build upon and subsequently increase EC usage so that as that FCT gets sold, there's actual liquidity to sell into.

If we create a solid foundation at $5.00 FCT and have to sell a lot of FCT around that price point to do so, so be it. We can then build higher and higher. But if we hunker down and simply weather the storm and the foundation is still shaky when FCT is at $20 and we start to sell FCT to build higher, it's all going to come crashing down.
 
Last edited:
Secured
#16
Speaking from a high-level:
I think that if a non-infrastructure ANO has filled their grant promises (or the equivalent of), then their is absolutely no reason that ANO should not be able to lower efficiency in order to tackle more projects. Right now, the incentive structure in this community incentivizes ANOs to literally do nothing and just collect FCT. There is nothing in place to demote or boot a non-performing ANO. There is nothing in place to incentivize a strong performing ANO. This is not good.

Therefore, because it will take some time to get a proper incentive structure in place, I would advocate for ANOs that have fully executed their pledges, and committed even more on top of that, to lower efficiency if they have projects they want to tackle.

In regards to to David specifically: Yes, he was an infra ANO. But he also already took on a development project and has been a huge contributor to the protocol since M3 launch. He's easily contributed more to the community as an ANO than he has taken out in FCT as an ANO. If we are not going to support someone whose output (contributions) is greater than his intake (FCT), then this project of ours might as well just fold up shop right now and call it quits.
 
Secured
#19
I saw on lowering efficiency from the other side.
I was a little prejudiced to this method of funding (there was the reason to think so, btw), so sorry about it.
The idea of allowance lowering if the contribution more than taken FCT has the right to exist.
But from the other side — we applied in 2 ANO rounds and both times Guides were strongly concerned about efficiency.

I think we should somehow to setup conditions, reporting and consequences of lowering in Governance document to make all clear.
I'm still concerned about how it can influence on the Protocol and market if more ANOs will start lowering or use floating efficiency. What will happen if 50% ANOs will lower/use float? Does we (community) mostly support it as usual practice or not?
What do you think about it Guides? Do you have a union opinion about it?
 
Secured
#20
LayerTech supports this effort.

The concept of efficiency and grant pool is really innovative, but we need to recognize that it is still a concept that is work in progress. As our community grow in number and complexity, the grant pool will also need to evolve to properly align changing incentive structure. We all know that, but we are waiting on legal review or someone to spearhead the reform. That will take a lot of time, hence David twiddling his thumbs in frustration. Instead of waiting months for proper reform, I support David and other ANOs to take initiatives now.
 
Secured
#21
@DChapman Is your list based on priorities or not? IF not could you do that? Some entries on the list are way more complex than others and some replace systems we already have in place (in a nicer way).

I get that you want to lower your efficiency instead of waiting for grants. I am supportive of that, but I really would like to see a list more in line with grant proposals and milestones/timelines in order to decide on that tbh.

To be clear (if not already from earlier statements). ANOs are entitled to lower efficiency on their own
 
Last edited:
Secured
#22
@DChapman Is your list based on priorities or not? IF not could you do that? Some entries on the list are way more complex than others and some replace systems we already have in place (in a nicer way).
They're not prioritized. Below is what we'd work on first (and would welcome community input). As additional needs arise, we'd be happy to adjust priorities.

1. There has been discussion about requiring specific time frames for discussion of topics and then specific time frames for votes on those topics. These types of requirements can be hard to keep track of. We would automate this process where when you create a certain type of topic that has a requirement for discussion and voting, the system automatically creates the discussion / vote with the required time periods. Email notifications would be sent to all pertinent parties warning them of deadlines.

2. When I tag a user by doing @[username] instead of a simple alert, that person would also be emailed. A new chain would be created on Factom for that alert which would create a timestamp. When the user viewed that alert on the forum, another entry would be made with the timestamp and it would show that user had viewed (or not viewed) that alert within the thread. This would improve communication, transparency, and avoid potential, "I never saw it" claims. Public statistics would be kept showcasing who views their alerts and who does not.

3. Create a system that tracks ANO pledges, update to their pledges, and a host of other information about ANOs that ANOs can update.

4. Factomize all "attached files" to forum posts. All uploaded content to the forum would be Factomized. It would in essence be a built in freefactomizer.com.

5. Thread by thread permissions. This has been requested by multiple people. Specify who can reply to, edit, etc a specific thread.

6. A robust committee system and committee page that shows current membership and lets people know how they can join.

7. Create the ability to have @[Authority Node Operator] and @[committee] alerts. Like number 2 above, instead of a simple alert, all members would also be emailed. A new chain would be created on Factom for that alert which would create a timestamp. When the users viewed that alert on the forum, another entry would be made with the timestamp and it would show that user had viewed (or not viewed) that alert within the thread. This would improve communication, transparency, and avoid the, "I never saw it" claims.

8. Create an "ANO Only" area of the site that provides a host of information that will especially be important for newly elected ANOs so they can get up to speed and make sure they're quickly integrated.

9. Factomize all polls on the forum. Each poll would have its own chain and after every vote and vote change, a new entry would be made.

10. Build an ANO and Guide Agenda and Meeting Minutes system into the site. With a single click, they can be Factomized.
 
Last edited:
Secured
#23
Before I start, like Niels says above it should be stated that governance gives you full right to drop your efficiency and no ano can stop you, you just have to be prepared for the consequence of damaged standing if you can't deliver in line with what your taking from the protocol (ie does Factomize fulfill its pledges at its normal efficiency, and dropping to 0% is Factomize able to deliver another apprx .6*2246*6=8k USD worth of value to the protocol, and is it arguable that those 8k with Factomize will have a larger impact than those 8k elsewhere). Those are the things that I will be looking at when judging whether an ANO loses standing in my eyes from something like this. All you can do now is get a sense of how people are feeling about the project, and all the rest of us can do is give you that sense.

Moving on, I support you in this project. Factomize has succeeded in my eyes so far, and I think you are well aware of the above risks and would not be embarking on this if you didnt think you could nail this.

Some questions on the above, and some just general thoughts on the proposals themselves,

1. Could this include something like during a discussion you could make a poll and if you had near unanimous you could override the time lock to open the voting period? Would be useful for things that you want a vote for but are clearly agreed upon by communnity quickly.

2. Could this tag tracking include if the user visits the thread again? I've got 708 unseen alerts right now, because I read all threads anyways and never click my alerts. If you wanted to know I had seen the @, it would be better to track when I revisit the thread, it wouldnt be proof but its evidence ;)

3. Can you talk more about what this would look like? How this would be different than a normal thread, like we are doing for grant updates?

4-5. Cool.

6. What would this look like? Again how would it be different than a normal thread? Or would this be more of a content thing?

7. same as 2.

8. Same as 6.

9. Cool

10. Very cool. Any other ideas of what could be done to better automate these processes? Also would have to make sure it was compatible and integrated with whatever method the guides are going to be using to sign the entries.

Another couple questions I would love an answer to.
-Will this developer be only doing forum dev work, or will he be getting to know the factom layer and how to work with our libaries and apis
-Lets say you do all of the above and are done in some number of months, and all else is the same as it is now in the factom ecosystem. Whats next?

Thanks!
 
Secured
#24
Thank you for your questions Julian. Let me first say that the thread by thread permissions would be our first project after talking to Quintilian.

Some questions on the above, and some just general thoughts on the proposals themselves,

1. Could this include something like during a discussion you could make a poll and if you had near unanimous you could override the time lock to open the voting period? Would be useful for things that you want a vote for but are clearly agreed upon by communnity quickly.
That's an excellent idea and yes.

Julianft said:
2. Could this tag tracking include if the user visits the thread again? I've got 708 unseen alerts right now, because I read all threads anyways and never click my alerts. If you wanted to know I had seen the @, it would be better to track when I revisit the thread, it wouldnt be proof but its evidence ;)
Yes, I would go by visits to the actual thread, not viewing the alert and am hoping we can improve the alert system so the alert disappears if you see the alerted post before going to the alert.

Julianft said:
3. Can you talk more about what this would look like? How this would be different than a normal thread, like we are doing for grant updates?
Not yet. I need to have a conversation with Q before I start designing the solution to make sure I don't step on toes.

Julianft said:
4-5. Cool.

6. What would this look like? Again how would it be different than a normal thread? Or would this be more of a content thing?
I envision a "Governance" navigation tab at the top of the forum that is a dropdown that lists various parts of our governance that lead to different pages. The "Committees" link would go to a page that in essence would be a nicer version of this: https://factomize.com/forums/threads/current-ano-committees-membership-and-tasks.276/ but automated. It would also list the requirements to join each committee and anything else that would help improve efficiency and transparency.

Julianft said:
. same as 2.
Same answer as 2 ;)

Julianft said:
. Same as 6.
This would be similar to 6 but an area ANOs have to be logged into to access that would provide any information pertinent to ANOs.

Julianft said:
9. Cool

10. Very cool. Any other ideas of what could be done to better automate these processes? Also would have to make sure it was compatible and integrated with whatever method the guides are going to be using to sign the entries.
I don't have ideas off the top of my head but they'll form as I begin to focus on this project :)

Julianft said:
Another couple questions I would love an answer to.
-Will this developer be only doing forum dev work, or will he be getting to know the factom layer and how to work with our libaries and apis
-Lets say you do all of the above and are done in some number of months, and all else is the same as it is now in the factom ecosystem. Whats next?
He will definitely be doing more than just forum dev work, especially since he'll be working with the Factomize Forum Addon. I'll want him to have a deep understanding of how it works and improve it over time.

We have some very large projects in mind but in the end, we'll do what's best for the protocol.