Fork Gridsync and create configs file specifically for S4 #470
Comments
|
Questions:
|
|
(not answering those questions sorry 😄 ) Implementation-wise, could we do this without a github fork - the config file could be an optional argument to the Makefile? Then we'd just need to keep a copy of our own config file and not have to keep a fork up to date with upstream GridSync. |
|
Essentially, yes. Currently, the config file is hardcoded to "config.txt" in the root dir of the repo (which various scripts read during the build process in order to determine the resultant application name, specify icons, etc.) so it would really just be a matter of copying a Least Authority-specific version overtop of that one (along with any icon files) and running |
|
To answer your questions: Since Least Authority is the company providing storage services, I think it would make sense to use the "LA" logo instead of designing a new one for S4, which is specific to Amazon S3 (and may just add to the confusion between all of these various pieces). For the description, I think we should say something like: I'm not sure what to call the user facing application. We could go with "Gridsync" but no where on the current website do we mention it, and people are already overwhelmed by "Tahoe-LAFS", "S4" and such. However, that would be consistent with the work you have started and we could add information to the website (which we should do either way). So, "Gridsync" could be the application to connect to grids, like the Least Authority S4 grid. Let's talk more about this. |
|
I think we should call the thing "Tahoe-GUI". (Or, we should have a thing called Tahoe-GUI that e.g. other grid-operators like Matador could provide to users for the "get tahoe-lafs setup and running on your machine). Maybe medium-term it makes sense to let these things evolve slightly differently? That is, "GridSync" does what it does, but Tahoe-GUI is 'just' (for now) the install + show-status part? I don't really have any strong feelings on which way is "better" though (just thinking that having two apps that do exactly the same thing but one is called Tahoe-GUI and one is called GridSync is weird). Also +1 for L.A. logo for the S4 grid. |
|
I'm also +1 on associating the "LA" logo with S4 within the application. It's what I already used in the recent screenshots/mockups for IFF too so, unless there's any objection, let's stick to that! As for the name, I'm not particularly attached to "Gridsync" long-term but it does already have a good deal of history and recognition with folks at Simply Secure, IFF, Internews, etc. such that it's probably best to keep that name alive in some capacity for the time being (and certainly for the remainder of the current UXFund funding period). I should mention that I don't think "Tahoe-GUI" is a particularly good name either, however (at least not for mass market purposes or in the long-term) since it gives no indication as to what the application actually does unless the user is already familiar with "Tahoe" and they know what a "GUI" is (and arguably, in the future, users shouldn't need to be familiar with these concepts in order to use S4 -- the first 's' does stand for 'Simple' after all ;) ). On that note, if we really wanted to reduce user-confusion (and I'm very much in favor of doing this), we could go the Dropbox route and collapse the user-facing distinction between application and service entirely, i.e., deploy the application as "S4" with the "LA" logo (such that users wouldn't even need to know what "Tahoe-LAFS" a "GUI" or "Gridsync" even is -- they just install the application, enter their invite code, and they're all set to start adding files/folders to the service via whatever means we provide to them in the GUI). Thoughts? Regarding what Gridsync currently does vs. what Tahoe-GUI was heading towards doing, they're now very much in-line: I removed my own watchdog/snapshot-based "sync" implementation a while back (and everything else that was interwoven with it) in favor of magic-folders.. It's now basically "just" installation (with |
|
"Branding" etc also impacts the trust model. My understanding was that we intended to have "one software" that you download from a single trusted place like tahoe-lafs.org (or leastauthority.com?) and then the branding 'comes with' the provider. If we go the other route (e.g. compile-time, burned-in branding that "comes with the app") then I think we should revisit the trust-stuff. In such a case, the users would have to download the software from their provider? (After all, if they're trusting them for service already, why not for software, too? And if not, would we be hosting N re-branding distributions?) In this case, the whole "invite code" thing is maybe moot, too: you just install the app and it has burned-in registration / login URLs/APIs. I think the first approach is better for "tahoe-lafs as an open-source project', better for provider-diversity, better for friend-net use-cases and better for leastauthority (e.g. we'd be "the source of the software" even for white-label/integration cases). This also has a better story for integrators: they just have to built a "thing that calls 'tahoe invite' or otherwise produces invite-codes" to tie into their existing login stuff instead of "build + distribute software to end-users safely, and integrate it with existing login stuff". This is likely way safer for end-users, too: we would be shipping software updates to everyone (i.e. not depending on third-party distributors to update before users get it). |
|
Excellent points. And yes, there are essentially two levels of "branding" that we should distinguish between:
I was under the impression (as suggested by the title of this issue and discussed previously) that the initial deployment was to be geared towards S4 customers specifically (i.e., as something akin to a limited beta test), in which case it becomes more justifiable to provide application-level branding in addition to the service-level branding that they already get (i.e., provide to users a "Least Authority S4" installable application that also connects them to the "Least Authority S4" service) -- the Dropbox model. Longer term, however, I agree that there should be a (singular?) application that would allow users to more easily join multiple grids of their choosing. Ideally -- and in the interest of minimizing conflicts-of-interest -- this would be a user-facing application blessed and deployed by the Tahoe-LAFS.org open source project itself (and/or be included alongside upstream In the short term, the most expedient step towards a solution to all of this might just be for Liz and I to write and propagate a leastauthority.com blog post in the not-too-distant future detailing some of the usability/user-engagement/collaboration work we've been doing lately (all of which was conducted under the "Gridsync" umbrella as per our grant with Internews/USABLE/UXFund and which they will probably want to see anyway -- along with folks at Simply Secure and others we've been meeting/talking/working with at IFF). Doing so would help to cement the project as one that's strongly associated with (i.e., sponsored/produced by) the company while helping to dissuade the notion that it's just the pet project of some dude (even though it certainly started out that way!). As a secondary effect, customers -- or potential customers -- of Least Authority who read the blog post get some insight into this hitherto mysterious "GUI" project that they've been hearing very little about such that when the application is deployed as "Gridsync" (if it is, that is) then there's no surprise and all of the dots get connected for us retroactively. As an added bonus, we get to signal our ability to meaningfully engage with the community (which we should probably be doing more of anyway) and maybe even reel in some of those elusive non-cypherpunk customers along the way. |
|
We already do have competition of sorts for storage space. There are:
...whom I would imagine might all like to be listed as "a provider" at some point after we release a GUI. Related to this, if the only way to "re-brand" / use "not S4" is to fork GridSync and re-release it, the longer we don't have "the one Tahoe GUI" hosted at tahoe-lafs.org we run the risk of this happening (e.g. Matador deciding to build + release a branded fork). |
|
Also, if part of our message (even if only subtext?) is "this is better than, e.g., Dropbox-style services" then maybe the "tight branding" thing is bad, too. (It might be more confusing for users: "I thought this thing I downloaded was S4? Why is it asking me to pay money/sign up/whatever to some other service?) |
|
Yeah.. If we go the "tightly branded" (i.e., application-level) route for S4 (which I only suggest as an option if the initial/beta deployment is intended to be for S4 customers only -- and which I'm now unclear on) then the functionality of selecting/joining a grid from a pre-given/built-in list should probably be disabled altogether to eliminate that sort of confusion. Personally, I'd like to remove that option for now anyway (i.e., force wormhole setups as the only method of joining a grid through the GUI) since, as it stands, the only grids listed are my own test grid (which has very low capacity) and the Public Test Grid (which has very poor reliability). A good compromise, however, might be to provide those options to the user at runtime (i.e., of choosing a grid from a built-in list of providers) only in the event that the application isn't "branded" at the application level. But even so, I'm not a fan of the idea of giving whoever controls "the one GUI" the authority to decide which providers are and aren't included (particularly in the event of multiple commercial providers being available). If only there was some sort of independent/third-party Tahoe-LAFS storage provider "market" service with a sweet JSON API that we could scrape. :) Dreaming aside, I suppose that the crux of the issue here still depends on the question of whether and to what extent the deployed application should be "specifically for S4". What do you have in mind @Liz315? |
|
This is a really important discussion! Hopefully, I can help by sharing my thoughts and summarizing your discussion into proposed answers: Initially, I assumed Tahoe-GUI would be more of a slimmer application and therefore would have configurations baked in. But then you all came up with the invitation code solution, which is better. Then we circled back to Gridsync's grid selection with the usability work and I am realizing that some flexibility is needed for the user, too. I don't think it is far off to believe people may want to be utilizing more than one grid provider, whether simultaneously or at the very least wanting to switch from one provider to another. For trust, I think it is important to offer people an easy way to switch, especially if we want to support a world with Tahoe-LAFS. Baking configurations in could prove annoying in that case (a user would need two applications?). Having multiple versions of the same software will be frustrating for users and I think harder for us, too. Plus everything mentioned previously. So, we stick with one version of the application for all providers, meaning we don't "bake in" configurations. Grid discovery and selection within the application: The application: To me, this means we should reverse some of the current Gridsync workflow. Example application workflow:
Step 5 is the part that we can wait on perfecting. I think getting 1-4 working for grid/service providers like us is key. 5 is where we can build a healthy ecosystem and grants and the internet freedom community can help to make the project have a bigger impact. For now, 5 could also just go to a webpage with explanation and a link to a list of grid/service providers and instructions to set up your own grid. As for branding: Could we just call the application "Tahoe-LAFS" and use the Tahoe-LAFS icon? Although I hesitate because it is such an odd name. I like the name Gridsync, better, but I fear we lose the decade of history and reputation of Tahoe-LAFS by going that route. And nonetheless, if we are distributing the application from Tahoe-LAFS.org and the grid/service market place is there, then the association is even stronger. Perhaps we can still blog about Gridsync being the underlying open source project for the Tahoe-LAFS application and Least Authority's contributions? This downplays Least Authority branding and levels our playing field, in a sense, but I think it is a big deal that we (and Gridsync) can take credit for seeding this and just be the best grid/service provider :) |
This all sounds great to me and we should talk to @warner about whether and to what extent he'd like this integrated with Tahoe-LAFS.org proper. Perhaps a simple Longer-term it would be great if this evolved into more of a "marketplace" type thing (perhaps hosted externally or by a third-party) with a searchable/sortable table with various information that might be useful in the decision-making process of selecting a provider (e.g., price, homepage/contact info, whether it's a single-node/location service vs. multi-node/location, whether they support/require Tor/I2P, whether they accept Bitcoin/Zcash, etc.). Originally, I wanted to have something like this built right into the GUI and available to users as part of the initial setup process (and currently do have a limited variation of it) but, after more thought and discussion, I'm not so sure that it's a good idea -- and not because I'm lazy or anything, but because the decision of who should be included for consideration should be one made by the broader community (and/or come as a result of the user's own research) rather than a single person. That is, if the GUI is meant to be impartial (i.e., not branded/configured towards being used for a singular provider), it should probably be impartial all the way. On the other hand, I really want the setup process to be as frictionless as possible, so providing some guidance in the event that the user has not already selected a provider remains desirable.
Yes. This is another example of what I mean (and which I spoke about in our panel session on Monday) with regard to drawing and keeping a distinction between a) information the user needs to use an application/service (i.e., perform tasks) vs. b) information the user needs to be convinced to use that application/service in the first place (i.e., values-based or "marketing"-type information). Arguably, a good UI for a desktop application should only require conveying the first type of information (which, if true, would give further justification to the idea of divorcing the "marketplace" type stuff from the application itself).
Yes. I wrote a quick document here explaining how to construct a valid invite code that would work with Gridsync (which storage providers could consult in delivering wormhole codes to their own users). I think that more tools should be available, however, to make this easier for storage providers (which might, as a consequence, result in the existence of more storage providers). @meejah has a branch with a
This all sounds excellent to me and, I think, strikes a good balance between strongly encouraging the use of the wormhole-based setup model while not leaving the user feeling abandoned (or having a Bad Experience on the Public Test Grid) in the event that they don't have a code.
Just to be clear: by "the branding could switch", you mean the branding of the service (e.g., as shown here and here) and not the branding of the application, correct? In any case, I'm thinking that the combo-box/pull-down menu in the current main/status window should be replaced with just the graphic/label for the "primary" grid (but then could turn into a combo-box/pull-down menu in the event that the user joins another grid). This would provide strong service-level branding (since the icon/name of the grid would appear at the top/center of the main/status window) while still providing the underlying flexibility of joining multiple grids and toggling the status view between them. Thoughts?
I'm also very hesitant to use "Tahoe-LAFS" (but would prefer it over "Tahoe-GUI") if only for the shallow reason that it gives very little indication on the surface as to what the application actually does (or at least it would require further explication that would be wasteful of the user's time). Beyond that, the design of the application (as it currently stands, at least) makes a conscious effort to conceal almost all of the standard operating "Tahoe-LAFS" lingo from the user ("fURLs", "mutable"/"immutable", "shares", "capabilities", "readcap"/"writecap", "servers-of-happiness", etc.). This is a good thing, I think, and gives us an opportunity to make a clean break from the bundensome concepts and language that already drive ordinary users away. Perhaps more seriously, Tahoe-LAFS does much more than a singular GUI probably ever will and I would hate for users to install the "Tahoe-LAFS.app" application and be disappointed by the (current) lack of functionality and/or make the mistake of thinking that it is Tahoe-LAFS when, in reality, it is an opinionated application that's built on top of Tahoe-LAFS and provides an interface for a very small subset of its features (it also depends on things that are not Tahoe-LAFS like magic-wormhole). The way I see it, "Tahoe-LAFS" is something akin to a protocol or spec (or "technology") that other applications could use in the same way that HTTP is a protocol/spec/technology that browsers use (Actually, I recall @warner mentioning something along the lines of "LAFS" being the spec and "Tahoe" being the python implementation of it). Just as we want to encourage an ecosystem of diversity among browsers (and not settle on a singular "HTTP-GUI.app"), we should want to encourage an ecosystem of diversity among LAFS-based applications. Crucially, this includes GUIs. I, at least, would love to see more friendly user-facing applications that use Tahoe-LAFS as a backend (or that are otherwise "powered by" or "secured by" Tahoe-LAFS) -- think password managers, blogging platforms, publication channels, things like NextCloud and more -- and so I worry that, by calling this GUI "Tahoe-LAFS" we'd be making an authoritative statement that is not only incorrect about what the application is but is also potentially discouraging of other creative efforts in the same space. All that being said, I'm wondering whether our collective efforts might be better served if we (leastauthority) outwardly focused on creating and marketing great (i.e., open source, secure, and simple) applications and services that are based on (or "powered by" or "secured by") Tahoe-LAFS/S4 than risk further muddying the (already very muddy) conceptual waters and hampering our own agility to develop new and awesome things on top of this old and awesome technology. |
Fork Gridsync and create configs file specifically for S4
The text was updated successfully, but these errors were encountered: