%CXac0yY0iJ5uf0nbIBN4AS6S6UmhK3WlrcqaYS/xFzg=.sha256%/AfExBHOmd+dIxpugZBEUrETxhJjlDiyx/ltbKGRaMk=.sha256%/tpIM+c9NOsi2285Om+SABKuYJ6hm1jnzM9mEVz47lA=.sha256I knew you were a freeze peach activist
%zIT8H2x0J0C7dpxOFDPXyr9L3N+MVvDIApsx1vUWKUY=.sha256I've been thinking about this a lot lately! Site creation should be accessible to non-devs! And it also shouldn't be a chore to developers. Themes and widgets can be fun to make, but they take too much time. How can we make the browser be an output multiplier?
I've been poking at a themes concept and I think it's starting to work. https://twitter.com/pfrazee/status/1158112442632871936. It's a somewhat natural tool to introduce for site creation... Beaker borders on being Wordpress or Gatsby, shouldn't there be a theming system? So that's where I'm iterating right now.
I think the p2p web is about accessible creation. How can entire web applications be convenient for end-users to create? It's important to non-devs so they're empowered; it's important to devs so they can work on real things instead of the same stuff repeatdly; and it's important to decentralization because it moves us away from big cloud deployments that handle everything.
%cPOx0g7U0koIik4XORZR4U0flNgmM4zgpmtLuDPuFo0=.sha256Hey really sorry to hear that ranger, 
goes out to you
%TLh/tyUpJ+2WAmM4R0KwrcT3JFbAaQzb3vszXUgsLA8=.sha256Just the standard pain points around multi-device and collaboration. I figure WYSIWYG and GUI-based construction are a long-term goal that we hit when we're trying to expand the audience.
%htsYvsPiuPnqo9FPU+TsZ7KaPOUi70RIecYmzO+aSBc=.sha256%1l1gUlNFB0Hau38lSF+TEVyLZ53V0UscoYFMcSAXGSQ=.sha256Been iterating a lot on ease-of-authoring lately (https://twitter.com/pfrazee/status/1155221334106017792). On top of convenient editor tooling, I'm really interested in composing the UI so that people can get a lot out of value from very little work.
One of the simplest tools for that could be a "theme" setting which injects css and js onto the page, grease-monkey style. You author unstyled html/markdown, pick a theme for your site or page, and you're set: the browser imports css & js from the theme dat. With web-components declaring new HTML tags, you'll even be able to get widgets imported from the themes. <paulstheme-recent-blogposts>, that sort of thing.
%vZEvSBwkcQWEF9ukLSITvjZQHHsa9q3cL+k4b8YIfQg=.sha256%NmLB9nDvvZ6gcDLCZFhL03VkqIOPUIf4a193jLid+d0=.sha256%2d1O1UDX0jlN44rnXuo+ITon8kz+Bx0LNjJlX0XNsvY=.sha256%mnVneuj+/RqFiltYUabWs19nIv8enoRpXzJ4x1p8zJ0=.sha256Sure --
I felt it was a real chance to build meaningful connections. The daytimes were familiar for dweb summits - lots of interesting sessions and talks and discussions. The camp fires at night were a cheerful setting for getting to know people. Having everybody in one space for the full weekend meant there were a lot more random chances for conversations, and usually those were my favorite; stuff like walking to & from my tent with Ben and DC while talking about mission, or an hour where I sat in the registration tent with Ross Schulman and the Archive interns and joked about total nonsense. I felt like I came away with new friendships, which is not something you get to say very often.
%S4tKBC6pJF3+lSbymv+rBNRu9gO5kQG7JpfluNdUKu8=.sha256Sure thing, happy to
%IBezKnRAW8LP796HACiZO0PjSYBcrlZ1DirWi4GC0EQ=.sha256%EuFsbKtTnbux3hxuxtn1AhIl0DcgaXT1Sok3PYkTRI8=.sha256Tell us something unexpected that was awesome! Just how much fun it was.
Did you drink tea? What was the flavour? Coffee!!
Are you new to SSB, how do you find it so far? So is it about butts that scuttle? Or is it about the butts of scuttlers?
Did you discover some new project there that excited you? Tell us more! I think holochain is really interesting and it was great to hear more about it.
What made you laugh? laughed a lot with @zelf :upside_down_face: playing ultimate rock-paper-scissors was a total blast and very funny
How were the chilly summer evenings on the tents? I brought extra blankets, the worst part was I couldnt wear the blanket through the day (soooo chilly)
Was it your first time camping? Did you like it? First time since my family had the camping trip from hell when I was 12. But that's another story.
%XLdkUljOvZdxYlPZTSg27PDHZlfWsYJn5jWOw3opmgI=.sha256<3
%UqIRwkTm0AUwGLTlCiAGFcEKDzbz+P+moOmE0GPkZ20=.sha256%SlQy0mRbeaUiYTdn5gV5nKPPIF8a0vFF6pWBrBPRQiM=.sha256%jiQF65bNRZzSxINTdiE8Z55nAqsa2aNJJnJWc06Z/pQ=.sha256%kuGxOhbgQ20HdkNjsuaUYcE+JX1MQ4/WR1EVKt29Exg=.sha256%R5sKBRtV/kLvcY+MwqbykjaR7TuJMcdEY9/I+GGe7CU=.sha256%6pcJvvhmc+J66Bf55QKItzOlX0oWsPX/E8H/23V3tco=.sha256%U2Cg6B45UxN66RXNsNErfOtfU0DkJ7ObgZd4MyQTJQc=.sha256I will!!! 
I think we're going to just need to start our own dweb gala, cowboy hats and boots mandatory (bc it'll be in texas yall)
%K0FsUu3CyiwLJ4g70tFzwj9a+5KGFvUF6Qfo+dj/ySs=.sha256%9kLrtMu4uRDYy3COV79qzt/I9qH34yKaCLdzYRJrZFE=.sha256%ih3hvceKjTzTcarJHJZL8i45A8UvJFRsxChez/J5G6Q=.sha256%Qhjt5Yd33wL7znRr5wfNUqXnH6R9+tMHY9wMvJc8r8o=.sha256%N7Y3+vhuZfnVtiJdIOyLWkxgX8RNSzWgwzZqN5ls5ro=.sha256%2RA1pLWWStQ+RKev6bvtAM5I2ToxOXeGP0HtmFZ09oI=.sha256%/hdPZ9wVl4c4yewEwx8W05ni45+WdQ/0GHSL0hFHNtU=.sha256%7qJW1SdbD3JmtPb5Wxjdip+RWckP2qTrSN/QKWkrh14=.sha256%/qISGFnYhRbVQVZ3Ur6Oq66D+5g1R4m0eklXdcXOEPo=.sha256%/2b9MqXnVJObThsdNAf8EzriCKp2zmDpmbexTdk+Cmc=.sha256{
"type": "about",
"about": "@hxGxqPrplLjRG2vtjQL87abX4QKqeLgCwQpS730nNwE=.ed25519",
"publicWebHosting": true
}%dLbgdrbEwKZf188LFqubXVGbsSJqcum8t4OodSkPi+Y=.sha256%XHmwsuCKmHKC7/tqzNukikNqn0M9wEFb/JcthAsxT1c=.sha256%LUVqAFC8/N/aKZGUMhHCzjlLMcSOJtmppT/S9X+8Pp0=.sha256%6fa/1DQwsdQui1AH7t8R4v5L3sohQadqcYL+t9+9HIo=.sha256%moGO8umHIFxPL1qkvKiBhnjsRNC9MDnE2BVo0sVUB94=.sha256%RuwLZHbzMnWFpVpjTxjoITNxgaAbYGXeaZA9i69ljzk=.sha256%ZRWPBRM/4DBUHqi/pi9mzALUspjX1mhCNs6OjOM8gGM=.sha256Heyy it was awesome to see everybody at dweb camp
%TLSvZCu4SHic8DjgthQ+TDN4UMtq/0syibyJxi7SQhM=.sha256Looks like it's going to be a Rush night 
%owgKnBi/0KoZrhNvDqX7s2fQZArDcH6K+xXIxmhztIg=.sha256%LmzxPEUlpT9xts+DbN9WCCeUC5i9yk48vgGITvoVLm4=.sha256%h0mKTM6aY4QyyQJWVX+kBSrsnxyBA75EyaH8oX4IsJE=.sha256%tpibqP/+akAnNDOmFqXj06lOAsnA3JFMbzeaJh6NVBU=.sha256%dMoNrEpyXt0tbm2Gl9espE4N6DtKZtwmM/piWufXV9U=.sha256Yeah we need to steal that in the dat world. Maybe apps can hook into the swarming system
%BN6oxrSiUMshWrJkSDeK/8oMO17J1CQDJC74rFCRQg0=.sha256Oh neat! Wish I could be there. I hope it goes great! Is there a tweet I can boost?
%SitBRXs2+fPXiiL1Ltifb4wGb6x9d25ZS0vVskSdfdA=.sha256%qPcy6SL+otUfQrlXEWWTkfG85ChrIDjvekvPMOvhf74=.sha256%Z5mKZf0u0ot++eYapBEQHVYLPD0WGbTQyTobBHCIc7w=.sha256%PRdDQpTl8fxK5Ahn/8XcFXKUX1J8o28qOMK5OUNph5A=.sha256%4xjTZgSiOr3IxDgcADC8217zlsmBkakaJN+tay+fmmM=.sha256%QxuxhG5wxpk1WVwqFLmqFfKXhOZc2I60h2uI0uHaFII=.sha256%TK02iseX/it1r8De38jJrS2j7uZOFWhUmmWmSm9MUc4=.sha256%/hgNJsIlWG6AjbzQor8GjILlpvgbYEDdpzzDCi7NBpo=.sha256%NHqLLdd9shddDjUSCTQXBT8qeWBQCck4ZP2pZdcNUps=.sha256%7l0RKAIj3FGgYv70h0FVFSqlnik6PSkxsdBQ2kdsYGs=.sha256Hey all 
I'm back into the buttz
Not much to share atm. I'm working on some beaker specs and I recently wrote an article titled why bother with p2p when you still need to guarantee uptime.
%uv9cD5EL9elMkiM6MkAJpbOSPSXMaINLeG401vUZGXo=.sha256IPFS's "nested URL" scheme was also a problem.
Beaker will get better.
%OafNI+TI8sZPZ9a2ogzVg0NIEYHhpzgLQR4pTtOHs60=.sha256%W8YsGmQGmiRDDX37B4q8pu8e2eyFWqRYXxNOyET9MnM=.sha256%6fd7CKEuZPK0gwLC2oZwabmFtfOH0reP+275kNZ0tvQ=.sha256%RuKS7TA974EhBK6sqxUfcHJ1QTHL6WAoA24RqFf/t+M=.sha256Hey wow these docs are amazing! https://ssbc.github.io/scuttlebutt-protocol-guide/index.html Nice nice work, really impressed. Congrats to everyone involved. Tara and I are inspired for our own docs work coming up.
I love the hermies variation icon in the header too
%qeeOpa29Tn+LNL/x5jTI4JldzOXz8swcR5s85GpK8CQ=.sha256@nanomonkey you could do that in jsonlz. Youd just name the schema the hash. Or you could put it as an added attribute on the vocab object ("hash" perhaps)
%1qhXu6RRm4TMnSYQ77v2kw2nc7Ber/7ccT7uRGqXI6I=.sha256Yeah, I think when it comes to identifying schemas, the only universally reliable technique is to use duck-typing. That's your baseline. However if you can get apps to agree on some metadata schemas to self-describe, then you get a slightly simpler process. That's one of the things that JSON-LD does, but I don't think it's very ergonomic for JS devs, so now I'm trying this alternative JSON-LZ. (SSB does this with the type field too but I think layering on JSON-LZ could be helpful and would work well.)
For your usecase, it'd help to have all of those teams agree on a metadata to identify schemas, but if not you'll need to munge off of duck typing.
The one other thing I'm trying to do, other than making munging simpler and have a nicer metadata schema than JSON-LD, is create a tool for identifying when lack of full support would create errors. https://github.com/pfrazee/json-lz/blob/master/DESIGN.md#well-defined-fallback-behaviors
%d5URnkHDQxDqLwFDmJ5EXwpJwJ9SzQpFgRagGreSKj8=.sha256%Rc8jhcxGS9mbviFi2OuCJNF575wFUo1zINEttpUKubw=.sha256@bobhaugen Here's what I've got on the design question right now: https://github.com/pfrazee/json-lz/blob/master/DESIGN.md. The project I'm trying (that repo) may not work out but we'll see, WIP.
%588UVx/fEyTBkwVbn7ITS3fea+jN/C6+AlcQWvaH7P4=.sha256Still working on the "handling schemas from multiple sources" question. I found a really superb article about how to approach this question, and I'm using it for inspiration: Don't Make Me Think (About Linked Data)
%cA2Nomfy1fwY3iJ4Nrhu6IPDJZCniFptANXUDzLbwHI=.sha256%QxHTa41x2P6sM0HZqQJ25DsnHzDvtTBrxw3JUVJpQ/0=.sha256When God wants to punish you he makes you listen to yourself in a podcast
%tITuNyxmM2UkmyIcIkET7TSBVvsVPPBExvumUfKi550=.sha256%98Evf7zjkWjunD/2TzhmER32kdIllXYaxpVNsyngPTw=.sha256I appreciate it @Chris ! Tara does too. I'm really excited to get into the docs again. I think we can make things even clearer than before.
%79oJUCYBBl+PQOqr59y2nfqBoEITSsZfowac4uC0+AM=.sha256%xZOlDIn3fEl2YPeogKfxV988PiXA8vCw3MTL/QcMGXU=.sha256%fmQGRXjQCCtIXoeLeBy4zOKnQu3yzx3Y+LsIvLB1ik0=.sha256Bad day for the crypto currency markets
%JXyDhNyBJ7IripATt0pCPdpiK3Bk3a/hwfnZAvEN0nU=.sha256%++Z0asCTfcp9o8OcTwg5mAWYUKYcLt9+3J6kuh3EMY8=.sha256%XwdqSTLLRk2Oci8/+1OKg8/i4sx+WnolDeV0+Mc61sI=.sha256@andrestaltz we're in agreement. My goal is to make development more fun and to only create solutions that devs are excited to use. This is my last post on that issue.
%0FrdQSrmISZCo8OVDaK29I0ykYkgEKfGXjLoUX1j884=.sha256%iAne//2u+Pbn34KV41PYAp1/LjXm7Ww3N/CvBtjNR1Y=.sha256%Av2nf02j2zU08wdQWSIDZlZ/uqoXH7UZoYXee8dzPMg=.sha256%UYGg3wr4p3sxg9QdutRxCXoRFmmbrgu7BaPGynTxPZM=.sha256%UBEo1cKIg0t5tv2a2amfNhxB4gip7gETrI0n/G9m2t8=.sha256Actually it's not like schema features are apps. It's like they're APIs. A schema is like the API to a function call that happens when another app reads the file. (It's a very async call.)
Schema design is API design?
%EFzdmMU3sLF1HSdcuN9SWuBtWKB0+N7JoLaXRZ4MifA=.sha256%0tq2VSjBVGN/f5ZTWfLzLPpw4QpyjonUKIqjOh4cILw=.sha256%I8ZEkpNPeXNkQRBLXaID5lRByiwG9rHp4k4mz3wIH6c=.sha256%VGFyxorcDIzR/y1vYu7ScrzZtWO4cbJFN8GeazCDNeQ=.sha256Awesome @Chris glad you had a good experience. We're hacking on 0.8 now and really excited to keep improving the DX and capabilities.
%9u7HDvY8LSd4cBQw7bayEEmNG8IspKzqItleln56xt8=.sha256%GLqW0EWb4RviO6kTnwcths6S27QsnFwSnZB77yuRzVU=.sha256%FR8Y2dJshPyU/KUMVvAZwaQ6xQje3jEg4k0dSZ8lamc=.sha256It's been interesting to revisit this! Everybody's making great observations.
Here are some my current takeaways:
- Fallback behavior. The most fallest backest is to show json. Showing nothing can cause chaos but not everybody wants to see json, so that's a tradeoff. Perhaps it's worth exploring some conventional fields for what to show when nothing works.
- Developer ergonomics. The DX is more important than "doing it right." Devs are going to do what they want. You can't force them to use something (like JSON-LD) so at best you can make sure the tools are good enough that they want to use it, and then make sure you tolerate chaos. (Robustness principle, also Worse is Better)
- No universals. Most of these decisions will end up being app-specific, and dominated by the apps in use.
- ...but Schema features are "app." I'm still thinking about a "requires feature" field, which devs could use to tell another client, "if you dont support this extension Im adding, please go to one of the fallback behaviors." Right now we have somebody in Rotonde trying to implement private-group posts, and they can't get Fritter not to show those posts on the feed. That's a similar problem to what we had in Patchwork when we rolled out channels. Rotonde needs a way to tell Fritter, "if you dont know what groups are, just dont render this please." And it'd be interesting for that to be configurable -- "please use the 'raw json' fallback if you dont support this."
So at this point, I'm talking to the ActivityStreams crowd (Mastadon and W3C Social WG) and theyre very hyped about their vocab and the potential for a compatible p2p world, so I'm trying to evaluate that.
I would be happy to change my tune, but I'd like to see an app where the killer feature is the schemas.
@dominic that's definitely the question here. Will these vocabs make devs happy (oh look at all the cool types I can use) or annoyed (how do I use this, ugh it doesnt do what I need). Tough call.
%7YkVCRk+//hm71n/+DlYBb2SJcB4dQVFHFL5y0ymfyI=.sha256%Z5tWqmnuVEJMZFjSar+h+ykhNtAr1LAeNd/6We3jb6k=.sha256%eLN3iXlMNth07lkCE0CsLDIdYS3hWfrZKQq/RF6j7NM=.sha256%E6BFsFZ8TJJW/6JT6embQCZhPN48Y3P1vBY7hX51Q4o=.sha256%p4c15CdsILTYLY9zJSR4AqcP8aQNiiKugMOTmVJPJhg=.sha256%Rr+xe48VvPL3kN8QbkckpZTW1ugBmzQp+KbspY0gjFY=.sha256%sJAuGcPoBNC8csG8/aI+nbV6xer26tTa9+QrPZFi2+g=.sha256%UEXjWNFlNT9Wd6W+SUbo+DBTkX7Gy5yk/8L6SO9yr9M=.sha256%z1nVPFfd4WOfqRwpfyVupwCEOiVi8xaHej1s9qUpiiA=.sha256%M/Z18lQVDlbFuxZeW4mtm3DGmceaDmDKJbQq+YeFGKg=.sha256Consensus is a funny thing here because it's variable. There's definitely some minimum of agreement required for apps to interoperate, but that minimum depends on each app, and that's where the discussion gets complex. If we're going to enable decentralized development, we have to support experiments and extensions, and create predictable results for everybody involved. It's tough, maybe impossible to do perfectly, but that's where my idea of declaring dependencies of feature-support within the schema is rooted (the requires attribute). When you imagine JSON records as documents, then you can see a parallel to HTML pages and how they sometimes do feature-detection ... so there's kind-of/sort-of precedent.
JSON-LD (JLD) is a solution about specificity more than agreement -- how can we make sure our attributes don't collide? In a way that makes it super amenable to non-consensus, because it's enabling everybody to do their own thing safely.
My problem with JLD is usability. I haven't seen any JLD APIs that make me go "ah yes that's easy to work with" much less one that makes me say "ah yes that's fun!" And I only want to use fun APIs. If we can solve that, and we can also make publishing namespace documents fun, then I'm on board.
@reconbot content-addressable is an interesting idea but it's very ugly in the code 
@andrestaltz that's such a tough call. I like being able to see the JSON but I think if devs could reliably predict, and therefore choose from, approaches that would cause their message to hide if not supported, they could make good enough decisions that a hidden message wouldn't be disasterous. In practice, I think devs will go out of their way to avoid totally hidden messages -- and will rely on generic attributes to make sure something can be rendered.
%lrzsUS9/u/LCll6+OlB0Fv3IK3VTnY+5na+ihV5zUak=.sha256Yeah! Thankfully Tara and I are working full time.
We are looking for funding, and we definitely want folks to build apps, but only if they feel compelled to. It's still pretty hard work because we haven't put together really superb guides.
Our long term sustainability plan is to (eventually) scale up hashbase and also sell home servers with a hashbase stack bundled. Hashbase is self-deployable so we'd be selling convenient deployments for folks.
(For those who dont know, Hashbase is similar to SSB's pubs. It's a dat rehosting service that gives you reliable uptime and -- someday -- more disk space for backups, and perhaps more. https://hashbase.io)
%ZPSDF802FcJtmgisOJVjqxVhW8LGPrTeoGmMg0iGk2I=.sha256%tMMt1T8VmJ8wdpkOttAc0PFM1RRBWWNslM1BCiRDB5c=.sha256%3BORHYiJ5cMq+K3anXycnYGADOLI35ljeT9KGEMyWm0=.sha256%eI1IGY0T+BEGfG2KOt3x4yohQWEXXMBLtimJ/MC487U=.sha256How is the SSB world handling message-schema compatibility these days? How, for instance, would an app add a new feature to the post messages like channels (if it didnt already exist)?
We've begun to discuss this for the Fritter/Rotonde world. We've got a couple JSON-LD/ActivityPub stakeholders this time around, to make things interesting. https://github.com/beakerbrowser/beaker/issues/820
%+luOtmWtjbTx/h3Vm1hfU1lR2rUpeaili5f4VCd1YXw=.sha256Heya @mix!
Lots of different priorities on the roadmap:
- Release Beaker 0.8. This should fix some usability that we feel the current release has. It's taken us a while to release for a couple reasons I'll explain below.
- Develope the applications stack. More on this below too.
- Revamp our docs so that hackers can figure everything out more quickly.
- Keep developing demo applications so that we can test the application stack. This is what Fritter is about. A few folks are using it and we don't know what the endgame is, but the main purpose is help us move the stack forward.
- Increment Hashbase's features a bit. Hashbase isn't our top priority, but two things we want to nail are custom domains and encouraging people to self-deploy.
- Brave Dat plugin.
- Switch Beaker from Electron to Muon to improve our sandboxing & security.
- Dat improvements. Improve the reliability of the Dat protocol (we've started work on integration tests) and roll out multi-writer support.
We spent the last 6 months figuring out what Beaker 0.8 should do. We kicked around a lot of ideas. At least 2 months went toward prototyping dead-ends but that taught us a lot about how to build apps on Dat. What we're releasing won't be a big surprise, but it'll hopefully be a much more refined experience than 0.7 is.
Our strategy is to make Beaker & Dat really enjoyable for hackers. We think a big opportunity is that Beaker/Dat can support 100% open-source Web apps with no devops. Eventually we want it so you can sit down at an app, open up the code, and just start hacking on it. We're looking at new approaches to Web security (like JS is disabled by default) and wondering whether more strict rules are actually liberating because we don't have to operate from the lowest common denominator of trust. And, we're beginning to look at compositional tools, including userland plugins, automatic loading of "viewer apps" when you visit Dat sites with no HTML, and ways to share user-profile Dats between apps in order to share datasets.
WebDB was a pretty solid step forward for the app stack. The internal fritter API, which should look a little familiar to SSB folk(!), was built on WebDB. Basically, WebDB is an indexer that uses indexeddb, so each app is currently building and syncing its own indexes. Works well for flexibility, but it's not very efficient with user's disk space. It'll do for now! Our next step for the stack is to make sure we wring as much value as possible out of Dat and the "pull only" architecture. Simultaneously, I've been exploring hosted crypto contracts (can we get trustless services without PoW?) and also reading up on federated systems like SOLID and ActivityPub.
So, that's about it.
%qKLzy4DmZMSRVj3/+1RhcM5RmuRw1yNG9Z5uWGXeDzE=.sha256%ETp8FRGq/BG6jItbMS3yRxYwcLprqCnAywpKfqztrwI=.sha256%GFDx/8k98yCkdtmgPAb+0kD4M786ZZnagU3EMj+aWXE=.sha256So does that caveat just mean it does not define how it affects the state of the server's backend file system?
Correct. The spec tells server-developers about various aspects of PUT. In general, PUT should be idempotent. -- ...
Oh geez, I just realized I said "idempotency of GET" in that blogpost, but that's not right. GET isn't idempotent, it's uneffectful. PUT is idempotent. Oh boy that makes me look silly. I'll need to fix that. Back to the conversation.
... -- PUT should be idempotent, but the spec doesn't say whether the resource should be republished "as given" at the target URL, which is what a filesystem would do. Many services accept the content of the PUT and then affect a variety of changes to the service state, and that doesn't need to include republishing the content of the PUT at the target URL.
So is SOLID refining PUT?
They're creating specs for generic server behaviors.
SOLID's API is specced here: https://github.com/solid/solid-spec/blob/master/api-rest.md#creating-content. It's the same basic premise as WebDAV, a spec for server behaviors, just less ugly (hopefully) than WebDAV.