Do we want to have an "official" bounty system for Freenet? Advantages: - It's essential to get buy in from the people who do the merging. Unofficial bounty systems have been tried, and failed, partly because of different views between users, donors and the people who do the merging. We don't want stuff to be paid for and implemented but never deployed. - BTC bounties are possible. Even paying developers anonymously. - Can use casual contractors, hire people when we have the money, not rely on having enough income to justify full time staff. - Agreeing a detailed technical spec in advance is probably a good thing, though there will of course be problems in practice. - There is far more work to do on Freenet than there are resources to do it right now!
Disadvantages: - Agreeing a price in advance may mean paying over the odds, even if we pay in BTC for something some of them may want to do. - Depending on how "official" it is, paying devs anonymously may be legally iffy. Long term we probably want the core devs to be anonymous anyway, and have a multiple sign off system for releases... "Official" here means getting buy-in from core devs before the project starts to fundraise. - We still have the possibility of paid staff; I should be full time from June 24th to October, and may be available in summer vacations after that. - Merging code, reviewing code, escrowing it, and so on may drain resources of core devs in much the same way as GSoC admin, if the devs are poor. - There needs to be sufficient trust on both sides. Who's going to control the escrow exactly? - Possibly over-dependant on Bitcoin. Ideally we'd like to start with a small "step" in a larger project, that can be individually funded. Obviously this is intended as a way to raise funds rather than to distribute them, though maybe it'd be worth spending some of the BTC we've accumulated to get it started. Some possible projects: - Update "streams", and other stuff related to distributing development over Freenet. - Content filter work. - Update the wrapper, in a 100% back compatible way. (C-heavy project) - BTCFN. This has already been started. What happened to it? Was it escrowed? IIRC the funds were raised but nothing has been heard since, at least not on the FMS board? - Rewrite the client layer: The splitfile code needs to be rewritten to use a robust on-disk flat-file structure per download. I can give a precise spec for this. The rest of the client layer should be stripped of db4o cruft and simply use serialisation (with backups). - Ambitious project: ECC-based SSKs/PSKs and advanced forums: -- Merge the pubkey and SSK stores, back compatibly -- Implement ECC-based SSKs -- Implement single packet 800 byte ECC SSKs, -- Implement 2KB maximum-that-fits-in-a-slot ECC SSKs -- Implement 32KB ECC SSKs -- Implement basic programmable verification i.e. PSKs -- Implement a simple wrapper for multi-signer keys -- Implement a centralised-moderation forum/WoT backend -- Implement a distributed forum/WoT backend. -- Implement forum-local global announcement. -- Implement a full blown forum client, which would have less spam/politics issues and be much faster and more scalable than even FMS is. - Rewrite the web interface. Thoughts?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
