One of the things about Sygn that I need to work on explaining more clearly is the role of the aggregators, even though my last post here did a much better job of explaining the total system.
To recap briefly. Sygn proposes a way for interested parties to create a cryptographically verified profile, which is a structured representation of data about themselves, their work, and experiences. This profile is then provided (published) and “aggregating servers” collect this information to provide people in need of services that might be provided by profile creators. The wins are: service providers are connected with potential clients in an ad-hoc many-to-many way, the provision of services is accomplished without relying on centralized commercial institutions, and intermediaries (i.e. aggregators) provide information to their users without incurring a lot of ongoing maintenance costs for maintaining the list of profiles.
The whole idea–and maybe this is a web-next-generation,1 in a web 2.0 world–is based on the idea that value is created not by collecting the most information, but by collecting the best information. We have lots of sites (e.g. LinkedIn. Oholo, Face book) which have been predicated on the notion that the site with the most profiles and the greatest number of connections between profiles, is the most successful. Sygn is predicated on the notion that site with the most contextually relevant collection of information is the most useful.
Lets present a case study to help illustrate the value of the aggregators in this “ecosystem” more clearly.
Velm is a free software project that provides an automatic real time document conversion service that lets users collaborate in real time using common editing tools by managing file synchronization and screen sharing. It’s a great tool for lots of people: enterprise users, small business teams, writers, people even use it to develop Role Playing Games. The problem is that Velm is a bit hard to set up, and it can be finicky if you’re not familiar with how some of the base dependencies work (i.e. ssh, samba, git, and rsync), and even though many different kinds of information workers would probably benefit from Velm (and often complain about the state of collaboration software) many don’t know how to use it. On top of that, there are some common applications for some kinds of work (audio editing, for example) which Velm doesn’t have very good support for, and some users want to be able to fund the development of Audio production support.
What we have here is a need for services and custom programming work around Velm. But where do these users go? The core development team is pretty small and they have day jobs and while they want to help address all of their users needs, they simply don’t have the time to provide that level of service and continue to develop the software. While there is a vibrant Velmian user community, the project leaders don’t have time to match support requests with potential providers, and they don’t have a good way of providing or endorsing a list of service providers to their users. The result: users are frustrated with Velm, developers are aware of the issue but can’t figure out how to solve it, there are some people who might be able to help in the community but there’s no way of providing useful information to the people who need it.
This is where Sygn comes in. Your comunity all make profiles, indeed the members of the larger free software community all make profiles, and these profiles would get “sent”2 to the server the Velm developers set up. Velm developers decide some criteria and ways of filtering the list so that it’s useful. They decide that unless the profile is signed by a trusted3 signature, mentions Velm, and availability for consulting work, they won’t include a profile on their server. With the list filtered down to something manageable, they create a template and a few indexes to make the information usable. Beyond that, the aggregate listens for updates, and rebuilds its index every day, or so.
Velm’s developers can provide a list of service providers, the list can contain user generated content (the profiles are generated by users), and Velm’s developers can filter based on any number of metrics: cryptographic trust, mention of specific Velm-related services and skills. Velm developers, as owners of the aggregating server have the complete authority to filter and sort what profiles got included in their server, in order to best serve their users. Users who want to learn more about Velm, or need help getting started, or need to sponsor some development, there’s a single list of potential providers, created by the community and the developers, without requiring either party the responsibility of keeping the information up to date, and organizing the information to best serve the users and potential users.
To continue with our metaphor, Velm isn’t the only user of Velm, there would be a lot of operators of Sygn aggregating servers. We can be certain, for instance, that the Cyborg Institute would run an aggregate to provide our potential clients with a list of our service providers. This would include the profiles used by Velm’s instance, but other instances as well. Our list would create value for our visitors, as we’d be able to filter it in such a way as to create profiles that would provide useful information to our clients.
A couple of notes:
The data presented by Sygn aggregators is not intended to be complete and authoritative for all profiles. Quite the opposite. Sygn is designed to work in a federated system, and the role of the aggregators is to create value not by providing the most profiles, but by providing the most useful profiles.
If you submitted your profile to a dozen aggregators, but no one would publish it, you’d be able to collect the profiles of yourself and your friends/colleagues to serve your users the best.
I can’t bring myself to say Web 3.0, really, but that’s the idea.
↩I don’t want to focus too much on the technology that would allow profile creators to “publish” their profiles, but I think it’s fairly safe to say that creating an interface for this would be fairly straightforward, though a single system would need to be devised.
↩I think it’s reasonable to assume that some application of the “web of trust,” system using PGP would be able to provide the infrastructure to allow profiles to be authenticated and filtered on the basis of “prestige” in the community.
↩