What kind of projects would it handle?
(Putting projects on this page is the beginning of the PicaProposalLifecycle).
The PICA track would include things like:
- XmlRpcFilteringPipe?, and the forthcoming HttpPipe?
- LocalNames?
- ULI, the UniversalLineInterface?
- CoEd?
- nLSD?
- OverHear?
- a method of instant signaling across the Internet
- various TextFilter? ideas ( Wiki:TextFilters )
- CommBot?
- code to make it easy to read from or write to the Open Clipart Library
- a HalfWiki? document store access interface
- an interface to get a directory of images from a wiki, and recommend methods for retrieving and posting images to the wiki (Could this be the same as WAIF, or is it necessary to invent Yet Another Slightly Different Protocol ?)
- WAIF - Webcomic Archive Interchange Format
- an EmailSystem? that is better than SMTP
- NgARN : Next Generation Amateur Radio Network
- VoP? voice over packet
- the Stop Foolish Rounding project, founded by Ward Cunningham
- new file formats
- "OpenSBP, a simple, free standard for CNC machine programming" by Joel Johnson 2009
- "an industry standard for tacking metadata [tags] onto ... any file. ... It would of course take years for such a standard to catch on. But it will be forever if nobody starts. ... The other approach would be to define a standard API for all metadata that all OSs could agree to implement in (at least externally) much the same way, Java and .Net and C library calls that would work the same everywhere, and even a command line interface that would be identical. ..." as discussed at "Who’s got the tag? Database truth versus file truth"
- "We want to stop fragmenting conversations on the Internet." -- http://salmon-protocol.googlecode.com/ , via "Real-time, Distributed Conversations: Some Thoughts on the Salmon Protocol"
- "Secure P2P for Pirates" by Grant Bugher discusses people working on improving the BitTorrent? protocol; they already have a few interesting ideas: "What they want to avoid is not detection per se, but rather the current consequences of that detection." "the resultant system could be useful for a host of purposes ... a sufficiently large peering system with deep storage ... could result in a sort of distributed information well in which any human knowledge could be stored for easy access and rendered almost indestructible."
I suspect that many of the formats are too cool for us, but it would be amazing to see things like XML-RPC, DOAP, Blogging APIs, MarkDown?, etc., join forces with us. That said, it is not our aim. Our aim is to find people who want to work together with us, and write our software together. Should that set of people share that aim, then we would want to work with them. If not, then oh well, too bad. No hard feelings.
better EmailSystem
Our current email system has problems that perhaps could be fixed if we switched to a better EmailSystem?.
Current system:
Ubuntu has (for the moment) standardized on the "maildir". "maildir is a structure for ... incoming mail messages. It solves the reliability problems that plague mbox files and mh folders."
... say something about IMAP ...
better system:
There seem to be 2 different categories of "better system":
- a system so different from what we have now that practically all my friends must switch over before I see any benefits. (... say, using Transparent Mail on a wiki that requires at least a CAPTCHA before posting a message )
- a system that can still send email to (and perhaps receive email from) the old system, allowing incremental upgrades. (Such as HashCash? and TMDA).
External links discussing how SMTP is fundamentally flawed:
External links to people discussing how to make a better email system:
Should we tell people on the various email-oriented wiki about this project?
- which project, the ones mentioned above, or PICA?
- Both. The "better EmailSystem?" project, currently hosted here at PICA. And also the PICA organization.
Brainstorming:
Is there some way we could build a "web of trust" and use it to block at high-volume email spam?
- At least one person in each city volunteers to be the anti-spam vigilante for that city.
- Each vigilante sends his public key and phone number to his counterpart vigilante in neighboring cities (and by "neighboring", I mean email flows through a single channel from one to the other).
- When someone notices a flood of spam flowing through a wire, he notifies the vigilante in the city "upstream" from him. (In a way that is unlikely to be spoofed).
- Each vigilante tracks down (?) which city the flow of spam is coming from, and notifies the appropriate vigilante.
- Once the stream has been tracked to its source city, the vigilante of that city figures out (?) which building it is coming from, and which wire (?) it is flowing through.
- The vigilante politely asks the people at that building to stop sending spam.
- If spam continues to flow through that wire, he unplugs it and confirms with the downstream people that was really the source of the spam. Perhaps he also makes a dramatic scene with a backhoe in front of the building.
- If a vigilante refuses to stop spam coming from his own city, then the next vigilante downstream from him disconnects the line between their cities. (Or perhaps adds a filter to block all email? All email that doesn't include today's captcha? All but 1 email per minute? )
- If a vigilante continues to refuse to stop spam, re-routing through other cities, eventually the vigilantes from all neighboring cities will cut off and isolate that city.
- It stays cut off until a new vigilante volunteers in that city.
/Brainstorming
I'm sure you could think of some other protocol that would work even better.
Is there any other wiki that is better for proposing and discussing anti-spam protocols?
other potential projects
including new file formats
In general, when we propose a new standard, what can we do to avoid or at least reduce the number of people ranting "This is not the way to go about introducing a standard. ... worse than not doing anything at all."?
- "A better way to post binaries on Usenet" that would solve many of the "10 or 20 problems" mentioned by "What's wrong with yEnc?". As of 2010, "This is a work in progress, not a finished standard. ... please don't turn all of Usenet into beta-testers ...".
- WAIF - Webcomic Archive Interchange Format "I want ... to mirror my existing webcomic. There are 952 strips in its archive. Is there a way to install multiple strips at once, or must it be done individually?" I suspect the web server could be set up to use standard FTP protocol; many FTP clients allow selecting and uploading or downloading hundreds of files in a single operation. Or is there some reason FTP won't work?
- So what is this "attention profiling mark-up language ( http://apml.org/ )" ?
- OpenRAW? ( http://openraw.org/ ): Digital Image Preservation Through Open Documentation. (I'm a little puzzled by the "DNG" specification mentioned here -- wasn't the "PNG" specification intended to losslessly store image information plus arbitrary metadata?)
- In addition to standardizing interfaces between web applications, perhaps we could also look into documentation standards. Documentation is kind of like an interface between humans (or between one human and, years later, the same human). For example, Guy Macon's Documentation Standards: rough draft.
- "PICO 1.0 - The Cross-Platform Icon Format" ht tp:// www.geocities.com/ajmas/pico.html
- People working on the Duplicity backup system are discussing yet another new file format: http://duplicity.nongnu.org/new_format.html
Rather than design a fresh new file format, perhaps some standard file format would work just as well (perhaps even better). This Pica wiki is the perfect place for you to describe what you are looking for in a file format; features that you haven't seen in the file formats you've looked at so far.
Even if there is no standard file format that will work for you, perhaps you could save time by basing your new file format on some standard meta-format:
- sBOX File Format Specification, defines sBOX, a meta-file format for creating file formats
- Flexible Image Transport System (FITS) is another meta-file format that may be useful for creating new 2D and 3D image file formats
- PNG allows backwards-compatible PNG extensions
- Many people (such as the people who designed the Java ".jar" file format) use the ZIP file format (using "zlib" to implement DEFLATE) as the outer layer of a new custom file format.
- the netstring format is close to the simplest possible format that can recover from sync errors; it's also human-readable for easier debugging.
- Put the name and version number of your format early in the file, so that you will be able to write software that can recognize and properly handle both version 1 files and version 3 files, and so Unix utility program "file" can use magic numbers to distinguish this file format from unrelated file formats.
- "XML: Half a standard is better than none" by Peter Seebach.
projects we missed out on
Alas, PICA missed out on: